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. Best, Christian -- Der Baum hat Äste, das ist das Beste. Denn wäre er kahl, dann wär's ein Pfahl. -- -- 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 vim_dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
