On 20-Oct-2011 17:12, Thilo Six wrote: > Charles Campbell wrote the following on 19.10.2011 22:22 > > Hello Charles, > > -- <snip> -- > >> 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. > > -- <snip> -- > > I believe you that vim does no parallelizm but maintainers do e.g. > 'syntax/php.vim' sources 'syntax/html.vim' which in turn includes > 'syntax/javascript.vim'. > There are also 'library' plugins out there which are used by others. > The variable name where the options are saved in should be chosen wise.
The script-local variables are still local to the script they're defined in, so there's no clash in variable names. Most scripts only define functions, commands and mappings while sourcing, but don't do any "work"; the real problem occurs when these things are used, triggered by the user. I don't see how saving and restoring options like 'ignorecase' during sourcing is of any help. (This mostly is only an issue for 'cpo', which most scripts save and restore already.) What is rather needed is a set of pushenv() / popenv() functions, which are invoked by each function / command / mapping during runtime (and you're correct about the issue with library functions). Still, I don't think that this, especially in a naive Vimscript implementation, would be a good idea; a single exception / script error would disrupt the env stack, so watertight try...catch would be necessary everywhere. On the other hand, a native :setscript would make Vim do all the hard work. -- regards, ingo -- 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
