> 2017-05-08 13:53 GMT+03:00 Bram Moolenaar <[email protected]>:
> >
> > 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.
> >
> > 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'.
>
> This can be emulated currently, and this is one of the worst approaches.
>
> Problems with emulations which may be worked around:
>
> 1. It resets place from which option is considered to be set (i.e.
> what `:verbose set option?` reports).
> 2. Care must be taken about regarding option scope, especially if “…
> do your stuff …” has switched buffers and windows. But unlike Python
> API Vim will not bark at you if you use `setlocal gdefault` even
> though &gdefault is a global-only option, it will silently set global
> option instead of what was requested (when creating Python API I
> intentionally made `vim.options` work with globals only,
> `vim.Buffer.options` work with buffer-local, etc;
> `vim.current.buffer.options['gdefault'] = False` is not going to
> work).
>
> Problems which cannot, not without breaking semantics at least:
>
> 1. If “… do your stuff …” raises exception and `call
> options_restore()` was not placed inside `:finally` while stuff placed
> in `:try` restoring options will never occur, presenting strange bugs
> to users.
> 2. Programmer may forget to do restoring on his own.
>
> One of the logical options would be introducing context managers,
> similar to e.g. Pythonic:
>
> `with … | stuff | endwith` works like putting `stuff` in `try` and
> making `finally` block. `…` may be the following:
>
> `with set sanedefaults`: temporary set a small selected set of options
> to default values and restore them after that. Suggested options:
> nogdefault, magic, noignorecase, wildignore=, fileignorecase&vim,
> maybe something else.
>
> `with let &option=expr1 &l:option2=expr1`: temporary set some options
> and restore them afterwards. Cares about where to restore them: e.g.
> if switched to different window/buffer restores option on the
> window/buffer where it was reset, or nowhere at all if those were
> wiped out.
Using a "context" / "endcontext" block could be useful to make sure the restore
is always invoked. It would work similar to a try/finally.
Whether there are more things to restore, I'm not sure if a context block is
the best solution for that. If so, there could be a way to add callbacks to
invoke at the end of the block. Go has a mechanism like that (always end of
the function though).
> Note: I am not fond of the idea of using `execute 'with …'`, so no
> `with set x=…`. No *at all*, unless you want to ban unfinished
> contexts inside `execute` because without banning them you can never
> get a proper parser for VimL. Currently things like `execute 'if 1'`
> work and if you allow `with set x=y` while having `with let &x='y'` a
> number of developers will for sure ignore `with let` and use
> `:execute`.
>
> Note 2: `verbose set option?` will report the SID context manager is
> running in for the duration of the context manager, then SID is
> restored alongside with the option value for both managers which
> save/restore options.
>
> Note 3: `with let` may be extended, but at start just supporting
> options is enough. Saving/restoring e.g. global settings of plugins is
> far less common because they are far less intrusive.
>
> `with saved input`: alias for using inputsave()/inputrestore().
>
> `with saved view`: alias for winsaveview()/winrestview().
>
> `with context expr1 [as var]`: user context manager, `expr1` must
> evaluate to a dictionary, treating this context manager like this:
>
> let _d = eval(expr1)
> if type(_d) != type({}) | throw 'Not dict' | endif
> let _enter = get(_d, 'enter', 0)
> let _exit = get(_d, 'exit', 0)
> if _enter isnot 0 && type(_enter) != 2 | throw 'enter not callback' |
> endif
> if _exit isnot 0 && type(_exit) != 2 | throw 'exit not callback' | endif
> if _enter is 0 && _exit is 0 | throw 'no callbacks' | endif
> if _enter isnot 0
> let var = call(_enter, [], _d)
> endif
> try
> stuff
> finally
> if _exit isnot 0
> call call(_exit, [], _d)
> endif
> endtry
>
> Notes: intentionally setting callback `self` to `_d` regardless of
> what may be saved there. Either enter or exit may be omitted, but not
> both. If `as var` was not provided return value if `_enter` should be
> just thrown away. Not providing any arguments to exit (Python provides
> exception details if it occurred) because expecting things like
> v:exception to be set. Calling `_enter` outside of `try`.
--
It is illegal to take more than three sips of beer at a time while standing.
[real standing law in Texas, United States of America]
/// Bram Moolenaar -- [email protected] -- 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 [email protected].
For more options, visit https://groups.google.com/d/optout.
