Ben Fritz wrote:
> >> What is the reason for only updating the default value of options, if
> >> P_WAS_SET is false? I get that we don't want to override the actual
> >> value of the option if the user set it to something, but don't we want
> >> to update the default value? E.g. shouldn't we do something like this,
> >> throughout option.c?
> >>
> >> int idx3;
> >>
> >> idx3 = findoption((char_u *)"shcf");
> >> - if (idx3 >= 0 && !(options[idx3].flags & P_WAS_SET))
> >> - {
> >> - p_shcf = (char_u *)"-c";
> >> - options[idx3].def_val[VI_DEFAULT] = p_shcf;
> >> + if (idx3 >= 0)
> >> + {
> >> + options[idx3].def_val[VI_DEFAULT] = (char_u *)"-c";
> >> + if (!(options[idx3].flags & P_WAS_SET))
> >> + {
> >> + p_shcf = options[idx3].def_val[VI_DEFAULT];
> >> + }
> >> }
> >
> > When the user has set the option that we must not change it back to the
> > default. When the user has changed the option, we should assume he
> > knows what he is doing and leave the value alone.
> >
>
> Right, I get that we shouldn't set the value of the option, if the
> user has already set it.
>
> But I would think, we should always set the default value of the
> option, regardless of whether the user has set the option or not.
>
> Do we gain anything by leaving the default value at the initial
> default, which will not work with the user's chosen shell?
It depends. If both 'shell' and 'shcf' are reset to their default
value, then we should not set the 'shcf' default to another value of
'shell'.
> Other options do this as well, I started updating shellxquote, etc. in
> the same area as my patch before I realized the same logic (or
> similar) applies to a large number of other options.
I think the best is to make "set to default value" trigger the logic
that decides on what the default value should be, instead of using a
string that was set some time in the past.
> > Only setting 'shcf' to the default would have to use the current value
> > of 'shell' to be right. Not some stored value for an older value of
> > 'shell'. I don't think we have logic for that yet, would require some
> > refactoring to trigger the logic to fetch the default value when setting
> > an option to its default value. Might be worth it though.
>
> Are you saying, re-default the shellxquote, shellquote, etc. options
> if the user changes 'shell'? That could be worthwhile...a little
> beyond the scope of what I'm trying to do here, though.
No, when the user changes 'shell' it should not have the side effect of
changing other options, because that causes great confusion. However,
it should be possible to do:
:set shell=myshellcmd
:set shellxquote& shellquote& shcf&
And Vim would figure out the best defaults, based on the current value
of 'shell'.
Does anyone see a problem with that? It's not completely backwards
compatible. But not too different either. Could perhaps be switched at
a minor release (Vim 7.4?).
--
hundred-and-one symptoms of being an internet addict:
196. Your computer costs more than your car.
/// Bram Moolenaar -- [email protected] -- http://www.Moolenaar.net \\\
/// sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\
\\\ an exciting new programming language -- http://www.Zimbu.org ///
\\\ help me help AIDS victims -- http://ICCF-Holland.org ///
--
You received this message from the "vim_dev" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php
