Hi ChrisBra, 2017-5-3(Wed) 18:11:16 UTC+9 Christian Brabandt: > Hi h_east! > > 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.
Wow! There was a person setting 'gdefault' so much! > > 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). Surely. It is better to delete the 'gdefault' carefully. Probably, I think that there is no big problem even if 'edcompatible' is removed. > > 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. I like 1. 2 seems more confused for me. > > But anyhow, either approach is okay for me. Thanks for search, suggest and opinion. -- 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.
