James - > On Wed, Aug 13, 2008 at 03:25:53AM +0200, Bram Moolenaar wrote: > > > On Thu, Feb 07, 2008 at 10:20:27PM +0100, Bram Moolenaar wrote: > > > > > On Wed, Feb 06, 2008 at 09:43:33PM +0100, Bram Moolenaar wrote: > > > > > > The main reason to do it this way is that when a startup script > > > > > > contains > > > > > > "set nocp" the following lines often depend on this. If one would > > > > > > start > > > > > > "vim -C" and the -C would cause the "set nocp" line to be ignored, > > > > > > the > > > > > > rest of the script would be misinterpreted. Especially for ":map" > > > > > > commands with things like "<C-A>". With 'nocompatible' this means > > > > > > CTRL-A, with 'compatible' this is 5 separate characters. > > > > > > > > > > The initial bug was specifically that "vim -C" with "set nocp" in a > > > > > startup script resulted in a Vim session that didn't have 'compatible' > > > > > set as per the man page. I notice that the help for -C indicates the > > > > > ":set nocompatible" command will override -C so maybe it would be > > > > > sufficient to add this to the man page as well. A similar note should > > > > > be added to the help/man page for -N. > > > > > > > > > > This would be a simpler solution, although I still think that if the > > > > > user is specifically requesting (no)compatible mode at the command > > > > > line, > > > > > they should be able to deal with side-effects it may have on startup > > > > > scripts. > > > > > > > > Well, a possible solution would be to do "set compatible" after all the > > > > startup stuff is done. I suppose that would work as expected. > > > > > > In thinking about this patch again, my original patch needs some more > > > work (which I've attached). The changes are as follows: > > > > > > 1) The original behavior of immediately calling change_compatible() when > > > -N/-C are parsed is restored. This allows the startup vimrc files to > > > have conditional behavior based on which compatibility mode Vim will > > > end up in. > > > 2) change_compatible() is again called immediately after the startup > > > vimrc files are sourced (only if -N/-C were given on the > > > command-line) so that the proper compatibility mode is set while > > > loading plugins. > > > 3) If the gui is started, change_compatible() is called one more time > > > (only if -N/-C were given on the command-line) immediately after the > > > gvimrc files are sourced to ensure that any changes they make to 'cp' > > > are overridden to follow the command-line options. > > > > Sorry, I have now lost track of the original goal of this patch. What > > was the problem being solved? > > It's addressing this item from the todo list: > > "vim -C" often has 'nocompatible', because it's set in some startup script. > Set 'compatible' after startup is done? Patch by James Vega, 2008 Feb 7. > > The initial patch I sent implemented the suggested behavior of calling > change_compatible() after all the startup scripts have been sourced. > > This introduces the problems (solved by points 1 and 2 from my previous > mail) that plugins/startup files being loaded will not know which mode > Vim is starting in. At least NetRW, and likely many other scripts > perform checks on whether Vim is starting in compatible mode. > > > Note that I have seen several people running into problems, because they > > were not aware of the side effects of setting or resetting 'compatible'. > > This usually happens when the option is set/reset after doing some other > > settings, which then get undone. Changing 'compatible' like it's done > > here might have the same problem, with the added obscurity of the user > > not seeing where it happened. > > The user is specifically using -N/-C on the commandline, so they're > expecting (no)compatible to be set when Vim starts (as we discussed in > previous emails quoted above). > > I had considered instead changing the patch such that -N/-C sets a > global variable to indicate that 'compatible' shouldn't be changed while > startup scripts are being sourced but I dislike this for a few reasons. > Mainly, it introduces another global variable for limited use and it > prevents the checking of which compatibility Vim will start in from > point 1 in my previous mail.
Now that I look at this again, I think we should not change this. I'll add a remark at the documentation for -C that startup scripts and plugins may change the option and you end up with 'nocompatible' anyway. If there are plugins that change the 'compatible' option, we should consider that a bug. Even changing it temporarily and restoring it has side effects. I rather have a clear problem than an unpredictable solution. - Bram -- SUPERIMPOSE "England AD 787". After a few more seconds we hear hoofbeats in the distance. They come slowly closer. Then out of the mist comes KING ARTHUR followed by a SERVANT who is banging two half coconuts together. "Monty Python and the Holy Grail" PYTHON (MONTY) PICTURES LTD /// Bram Moolenaar -- [EMAIL PROTECTED] -- http://www.Moolenaar.net \\\ /// sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\ \\\ download, build and distribute -- http://www.A-A-P.org /// \\\ help me help AIDS victims -- http://ICCF-Holland.org /// -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]