Thilo Six wrote:
Charles Campbell wrote the following on 19.10.2011 17:11
-- <snip> --
I suggest looking at pluginkiller
(http://drchip.0sites.net/astronaut/vim/index.html#PLUGINKILLER) - it
has a large list of options which can cause plugins grief.
Regards,
Chip Campbell
Yes indeed. Thank you.
Apart from from what already has been said. I think the approach currently taken
to ensure inside a vimscripts to get a reasonably state is broken.
E.g. currently settings get usually stored in a variable at script begin and
then restored at script end.
As the option that are most critical are without exception global only how do
ensure to not get into a race situation? Is it 100% ensured that all
runtimefiles are loaded serial, even in a multibuffer session?
I don't think getting a reasonable state is broken, just difficult.
Essentially plugins should let the users' options remain intact so long
as they don't adversely affect the plugin's operation; however, figuring
out which options need to be bypassed can be difficult.
(by bypassed: I mean: save user option, set to plugin-safe value,
restore user's option). However, bypassing an option affects the
:verbose map ...? results.
Vim is not parallelized; ie. plugins are loaded one at a time, so
there's no race situations possible. There can, however, be sequencing
issues. The runtime path is examined from left to right, and scripts in
each directory appear to be loaded alphabetically.
I wish there was an envpush/envpop pair, myself. There is a real
problem in "restoring user maps" (ie. referring to my "bypass" again,
but this time applied to maps). There was a prior discussion about map
restoration; the problem involves options such as <buffer>, <silent>,
etc. I'd like plugins to be able to save user maps, override them, and
then have the plugin provide a deactivation (which would restore any
conflicting user maps). Consider DrawIt; it sets up a lot of maps, but
:DIstop is supposed to restore the pre-existing state (including user maps).
Regards,
Chip Campbell
Regards,
Chip Campbell
--
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
