Bug#438560: Should -N/-C override 'compatible' settings in vimrc files?

[James Vega]

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.

-- 
James
GPG Key: 1024D/61326D40 2003-09-02 James Vega <jamessan at debian.org>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: Digital signature
Url : http://lists.alioth.debian.org/pipermail/pkg-vim-maintainers/attachments/20080812/ea1d5726/attachment-0001.pgp