суббота, 12 января 2013 г., 20:29:58 UTC+4 пользователь Bram Moolenaar написал:
> I like the idea. But doing this specifically for functions may not be
> the best solution.
Why? autocommands, mappings and commands almost always call functions that do
the action for almost any plugin that is more complicated that "Hello world".
:map-<defaults> is not so needed.
> I'm also not sure if this specific set of options is correct. We have
> the habit of setting 'cpo' to its Vim default in plugins, I wonder if we
> really need the others. 'remap' and 'magic' should always be at their
> default values.
If 'remap' and 'magic' are required to be at their default values then they
should be removed as they do not make sense. Current set of options was deduces
after examining options.txt.
About 'cpo': some 'cpo' flags affect function behavior, so it is irrelevant
whether or not you set it in script:
fu!Abc()
cd ..
endfu
set modified
set cpo+=.
call Abc() " fails
set cpo-=.
call Abc() " Succeeds
. You will observe just the same behavior if function is surrounded by cpo
saving/restoring code.
> I think there are two ways to use the functionality:
> 1. Save the option values and automatically restore them when leaving
> the scope (function, script, or something else)
> 2. Save the option values in a dict, and restore them when desired.
There are two good things about "emulate -L zsh": a) it is standard; b) it
requires adding only one line of code. Exact set of options may be discussed to
achieve purpose of making functions user-configuration-independent, but there
must be standard and quick way to get rid of intrusive options effects. Both 1
and 2 can be achieved using built-in :try/:finally and some utility functions,
but it is too much effort and it slows down vim much more then :fu defaults
handled only in C code. If you suggest some other C equivalent and not some
utility functions then I do not understand how both should look like.
> The second one gives more control, but requires more care from the
> script writer.
This defeats the second purpose: fast way to achieve this functionality.
> When these are implemented with a function, you could do the same as
> what your patch does and more, right?
Yes, but this defeats the first purpose: standard way to achieve this
functionality.
--
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
