On Mo, 08 Mai 2017, Bram Moolenaar wrote:
>
> 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'.
Would those then also be set to a default by options_save? Or does every
plugin write have to set them as well?
Also worth containing: 'magic', 'cpo' and 'cp' options.
Best,
Christian
--
Auf welcher Gesetzestafel steht: Die heiligen Gefühle der Theisten
müssen respektiert werden, die heiligen Gefühle der A-Theisten aber
nicht?
-- Ludwig Marcuse
--
--
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.
