Justin M. Keyes wrote: > On Mon, May 8, 2017 at 12:53 PM, Bram Moolenaar <b...@moolenaar.net> 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.
True, some options are only there for Vi compatibility (or Posix standard conformance). But removing them doesn't really have a benifit either. > In the UB thread[1] it was implied that 99.9% is the target audience: No, that's completely out of context. > > 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. Please don't insult our users. There are lots of features they haven't discovered yet, sure, it's really up to the user how much time he wants to spend finding better ways to do something. Also, there have been features added that turn out to get very little use, no matter how enthousiastic people where when it was introduced. It might be better to spend time on helping users find and use the existing features, than adding more of then. E.g., I am often suprised people don't know of persistent undo. > [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. It's in the todo list, but apparently nobody has taken on the job of working on this. I admit it's going to be a bit of work to refactor the code to handle the side effect of changing an option (instead of a very long if-else statement). Anyway, how does this relate to new features? Or perhaps we should first fix existing features before adding more? (that might then have bugs again). -- Why don't cannibals eat clowns? Because they taste funny. /// Bram Moolenaar -- b...@moolenaar.net -- http://www.Moolenaar.net \\\ /// sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\ \\\ an exciting new programming language -- http://www.Zimbu.org /// \\\ help me help AIDS victims -- http://ICCF-Holland.org /// -- -- 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.
