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