Bug#438560: Should -N/-C override 'compatible' settings in vimrc files?
Bram Moolenaar
Bram at moolenaar.net
Wed Aug 13 02:58:21 UTC 2008
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 -- Bram at Moolenaar.net -- 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 ///
More information about the pkg-vim-maintainers
mailing list