Hi Bram and all,

2017-5-8(Mon) 19:53:37 UTC+9 Bram Moolenaar:
> 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.

Certainly I have proposed to remove the option easily.
That's right, I should suggest a good solution before choosing to remove the 
option.
You have maintained "Vim specification" for over 20 years.
I don't know if your judgment is always right :-), but I would to respect your 
opinion strongly.

> 
> 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'.

For 'ignorecase' and 'smartcase', We have `\c` or `\C` that can ignore that 
setting.  (`:help /\c`, `:help /\C`)
Also, for 'magic', We have `\m` and `\M`.  (`:help /\m`, `:help /\M`)

It may be good if there is a similar mechanism for 'wrapscan', 'gdefault' and 
'edcompatible'.

Thanks.
--
Best regards,
Hirohito Higashi (h_east)

-- 
-- 
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.

Raspunde prin e-mail lui