On Wed, May 3, 2017 at 11:11 AM, Christian Brabandt <[email protected]> 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. 'gdefault' is a misfeature that probably can't be removed, though I would be in favor of it. 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. --- Justin M. Keyes -- -- 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.
