On Mon, May 8, 2017 at 12:53 PM, Bram Moolenaar <[email protected]> wrote: > > 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.
That's true, but in the case of 'edcompatible' the usage is << 0.01%. And probably accidental. In the UB thread[1] it was implied that 99.9% is the target audience: > The C language was originally made for a wide range of CPU, even weird > ones. Now that 99.9% of computers are fairly standard it would be a bad > idea to suffer from supporting those conrder cases. Not only that, but decisions about Vim's default behavior have _benefits_ for most users. So it's incomplete to only analyze potentially "harmed" users, without also balancing against potential benefit. There's also no purpose in optimizing for the use-case of users that literally don't care about any new features in Vim. Yet Vim continues to orient itself towards this "silent majority" of users that leverage Vim as a glorified Notepad. [1] https://groups.google.com/d/msg/vim_dev/_tqf8eQy5eA/jhHqnroaCAAJ > 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'. Sure. Meanwhile, `:set all&` still has bugs. --- 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.
