RFC: Two option-handling techniques for scripts
Ben Fritz
first-hand experience, I have learned that one of the biggest hurdles
to writing a robust vim script to distribute to other people is
dealing with the hundreds of options that Vim has, many of which
potentially cause your script to do unexpected things. Dr. Chip has
even made a plugin that attempts to check these options in an effort
to make things easier, but I have not heard it mentioned very often.
I propose two alternate methods to solving this problem, each of which
add new functionality and should therefore break no backwards
compatibility (though it will cause scripts utilizing the method to
not work on older Vims without the functionality; I would think this
is to be expected).
Method 1: Script-local options
We have the ability to "let" variables that are global, local to the
tab, local to the window, local to the buffer, and even local to the
script and the commands defined in the script. Why not add this final
category to options as well?
This method would add a command, :setscript, that behaves just
like :setlocal, except that the option will only be read during script
execution, or during execution of commands defined in the script.
Typical use would be as follows:
setscript all&
setscript ignorecase
" load the smartcase option from the local 'smartcase' option defined
by the user
setscript smartcase<
...more script-local options, as needed, to override the defaults...
...Commands that execute with a KNOWN configuration...
At the end of the script, user settings will be unaffected. The script
writer can choose on an option-by-option basis whether to use a user
setting, or define their own. Commands defined in the script need not
worry about saving and restoring relevant options, making them far
less complex.
This method would obviously require a LOT of effort to implement, and
certainly cannot be implemented in vimscript, but would probably be
the cleaner of the two.
Method 2: create an "option stack"
This method was already discussed here, briefly, in the middle of this
thread:
http://groups.google.com/group/vim_dev/browse_thread/thread/92bce4a37ae9858f/07cda2bd46fc62b4?lnk=gst&q=option+stack#07cda2bd46fc62b4
Typical use would be as follows:
optionpush
setlocal all&
...
command foo optionpush | call s:Func() | optionpop
...
optionpop
Again, script writers would be able to easily execute their entire
script in a know configuration, and easily restore all options at the
end without setting each one individually. Commands defined within the
script would need to set and restore the options during command
execution, however.
This method has the advantage that it could probably be implemented
using vimscript, and as long as it was distributed with the official
Vim runtime files, script writers could assume its presence. However,
I believe it would be far better if it were made a built-in function.
I imagine, since :set with no arguments currently displays all options
set to non-default values, and there is an easy way to restore all
options to default values, that this method would take fairly little
effort to implement as well.
What do people think? What are the advantages/disadvantages of each
method? Is there any chance of either of these actually making it into
Vim? How useful would something like this be?
Charles Campbell
> >From many discussions I've had in the past, and from my own limited
> first-hand experience, I have learned that one of the biggest hurdles
> to writing a robust vim script to distribute to other people is
> dealing with the hundreds of options that Vim has, many of which
> potentially cause your script to do unexpected things. Dr. Chip has
> even made a plugin that attempts to check these options in an effort
> to make things easier, but I have not heard it mentioned very often.
>
FYI -- that's (probably) PluginKiller
(http://vim.sourceforge.net/scripts/script.php?script_id=1489)
> I propose two alternate methods to solving this problem, each of which
> add new functionality and should therefore break no backwards
> compatibility (though it will cause scripts utilizing the method to
> not work on older Vims without the functionality; I would think this
> is to be expected).
>
> Method 1: Script-local options
>
> [snip]
>
> This method would add a command, :setscript, that behaves just
> like :setlocal, except that the option will only be read during script
> execution, or during execution of commands defined in the script.
> [snip]
>
Sounds good to me; sounds like my attempts to save&restore options,
except to push that capability into vim. I'd hope that setscript would
avoid the option-last-set-from (the scriptname here). As is, the
save&restore means that the script which does that effectively prevents
knowing what, if anything, really changed the option last.
There may be complications with multiple
setscript &all
calls -- as in when should it, if ever, be ignored, and when should the
options be restored. I'm thinking about a script that calls upon a
different script's mappings/commands/functions/whatnot. Some scripts
have multiple entry points, and so may themselves have multiple
setscript &all calls within them (or perhaps multiple ways to call the
same function with a setscript &all call).
> Method 2: create an "option stack"
>
> This method was already discussed here, briefly, in the middle of this
> thread:
>
> http://groups.google.com/group/vim_dev/browse_thread/thread/92bce4a37ae9858f/07cda2bd46fc62b4?lnk=gst&q=option+stack#07cda2bd46fc62b4
>
> Typical use would be as follows:
>
> optionpush
> setlocal all&
> ...
> command foo optionpush | call s:Func() | optionpop
> ...
> optionpop
> [snip]
I'll mention one option that this process doesn't help with:
equalalways. Setting it causes the window sizes to be adjusted, so one
cannot do a save&restore and avoid the option's effect. There may well
be other such options which affect things immediately upon being set.
This problem with immediate effects may affect the setscript idea, too.
The "option-last-set-from-..." information is also polluted.
Regards,
Chip Campbell