Hi Justin, 2017-5-3(Wed) 18:44:14 UTC+9 Justin M. Keyes: > On Wed, May 3, 2017 at 11:11 AM, Christian Brabandt wrote: > > 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. > > > > 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. > > Neovim removed 'edcompatible', we've received zero complaints about > that.
Yeah, I knew you removed it. But I didn't know without any complaints. Thank you for telling us. > 'gdefault' is a misfeature that probably can't be removed, > though I would be in favor of it. As you say, it seems that it can't be removed immediately. > > Approach (2) would open a great opportunity for removing a lot of pain > of writing plugins. The fact that it hasn't been done in the last 20 > years makes me think there is too much uncertainty about the > side-effects; it's an obvious approach that should have been taken > long ago, but now the technical debt has piled up. "now the technical debt has piled up" Good words. I think so too. It isn't preferable that the meaning of flag is reversed by the option value. Or We should adding a flag that does not affect the value of the option. e.g.: 'i' and 'I' flag that not dependent on option 'ignorecase' and 'smartcase'. -- 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.
