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.
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`.
>
> --
> Kisses may last for as much as, but no more than, five minutes.
> [real standing law in Iowa, 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.
--
--
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.
