On Oct 17, 8:29 am, Thilo Six <t....@gmx.de> wrote: > After thinking a little bit more about this issue I would like to ask you > Bram a > question about this. > Currently the approach seems to be that a vim script has to create a sane > environment on its own. > Maybe we should change that paradigm to: > When a vim script wants a insane environment it has to create it on its own. > > That means basically that we change vim to parse each file from $VIMRUNTIME as > if it would have been preceded with 'set cpo&vim'. > This basically leads to changing cpo from 'global only' to 'script local > only'. > The advantage seems to be, that vim would actually behave as script > maintainers > silently expect. >
This won't be a fix-all as expected. You'd still have a problem with autocmds, mappings, etc. which would still execute in the context of current user settings, especially for the cpo-l setting you mention. Obviously line continuations would be something that pretty much only affects the initial :source-ing of a script, but many of the options have an effect every execution. And, cpo isn't the only "problem setting". Many script authors make assumptions about 'magic', 'selection', and others. Even the very good surround.vim plugin screws up with 'selection' set to exclusive. We cannot truly ignore ALL these settings in sourced scripts. And, how would you tell the script, "use whatever option value the user currently has set" using the suggested scheme? I've seen at least these suggestions: 1. Have an "envpush" and "envpop" command (or similar) which would create a restorable state of all options which could be pushed and popped at will by script authors. Authors would do "envpush" at the beginning of each script, and at the beginning of each function, then "set all&", then "envpop" and the end of the script/function. 2. Have script-local options similar to buffer/window/tab/script-local variables and buffer/window/tab-local options. This would introduce commands like "setscript" and a new pattern similar to :set cpo& or :set cpo< which currently set the option to the default or to the global value, to set a script-local option to the current local/global value. Any options set local to the script would retain their value in mappings and autocmds, similar to how script-local variables work. Authors would probably ":setscript all&" at the beginning of the script, and individually set options which ought to use the user settings to do so. 3. Leave things as-is, and rely on script authors to find and account for problem settings. There are plugins to help with this, I think Dr. Chip has one on his site. Note some settings are often used to solve actual problems, e.g. the 'shellxquote' on Windows, whose default value messes up external command evocations which have spaces: http://groups.google.com/group/vim_dev/browse_thread/thread/3d1cc6cb0c0d27b3 -- 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
