Christian Brabandt wrote:
> On Mi, 03 Mai 2017, h_east wrote:
>
> > 'gdefault' invertes the 'g' flag of `:substitute`.
> > In addition to 'edcompatible', it also inverts the 'c' flag.
> >
> > When using `:substitute` with plugin, save and restore of the above options
> > are necessary, it is a little weird.
> >
> > I propose to stop supporting these options.
> > Please check the attached patch.
>
> I made a little github code search for some vim settings. The results
> are a bit surprising:
>
> Search Term Results
> -------------------------------
> set edcompatible 6
> set gdefault 8,289
> set langnoremap 718
> set nolangremap 207
> set termguicolors 3,425
> set t_Co 98,886
> set laststatus 75,336
> set nocompatible 94,745
> set incsearch 79,623
>
> So gdefault seems to be popular to a certain degree. I wouldn't have
> thought that, it is just such an obscure option.
>
> By contrast the usage of edcompatible can be neglected, that option
> seems to be in almost no use. Somewhat surprisingly, 'langnoremap' is
> still somewhat widespread, also it is replaced by 'langremap' option.
>
> The relative newly introduced option termguicolors already seems to have
> widespread (at least it is already used more than the langnoremap
> option, which was introduced earlier).
>
> I also included a search for settings I expected to be in wide use, e.g.
> 'nocompatible', 't_Co', 'laststatus' and 'incsearch' and that seems to
> be the case.
>
> Coming back to the topic:
> I am all for removing those options, however this is a hard change that
> may break scripts and will probably also annoy users (especially of
> 'gdefault', from which I would expect several bug reports, if that
> option will be dropped).
>
> I see two possible solutions:
>
> 1) start echoing warning messages, that those options are deprecated and
> after a grace period (e.g. the switch to Vim9) remove those options.
> 2) make a distinction between interactive usage and script usage and for
> the script usage provide a clean environment where those options are not
> set, so scripts/functions do not need to handle that. That could also be
> enhanced later for other settings or even mappings.
>
> 2 seems to be the cleaner approach and does not bug the user much, so
> that might be preferable. However I don't know how hard to implement
> this would be.
>
> But anyhow, either approach is okay for me.
The problem with removing options is that you always hurt some users.
And most probably the ones that just use whatever they have on their
system. Thus complaints might come very late. Neovim is certainly not
a good indication, because these users have made a choice to use a
non-standard Vi/Vim.
Also, when one option only has 0.01% usage, and we remove a dozen of
them, we are already at 0.12%, one in a thousand users. That's likely
more than users of more advanced features.
Besides that, plugin writers also have a problem with very common
options, such as 'wrapscan' and 'ignorecase'. We are nog going to
remove these. Having an easy way to set these to their default, and
restore them later (without side effects), would be very useful.
For flexibility this needs to work recursively. We could do something
like:
let saved_options = options_save()
... do your stuff ...
call options_restore(saved_options)
The options being saved should be small to keep this efficient. We need
to make a list of the ones that are useful, such as 'ignorecase' and
'gdefault'.
--
Kisses may last for as much as, but no more than, five minutes.
[real standing law in Iowa, United States of America]
/// 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
---
You received this message because you are subscribed to the Google Groups
"vim_dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
For more options, visit https://groups.google.com/d/optout.
