Bug #105899 for Perl-Tags: test causes vim to fail if any plugins using line continuations exist

Thu Jul 16 07:16:05 2015 KENTNL [...] cpan.org - Ticket created

Subject:

test causes vim to fail if any plugins using line continuations exist

vim -u _vimrc implies that the default, "nocp" is disabled.

Under compatibility mode, line continuations are disabled.

Thus, the absence of a ":set nocp" in this vimrc causes any plugins that vim loads using line continuations to fail.

For example:

When vim attempts to load:

https://github.com/vim-scripts/Briofita/blob/master/plugin/briofita-support.vim#L127

It fails with

Error detected while processing /usr/share/vim/vimfiles/plugin/briofita-support.vim:
line 127:
E723: Missing end of Dictionary '}':
E15: Invalid expression: { "statusline": "StatusLine",
line 128:
E10: \ should be followed by /, ? or &
line 129:
E10: \ should be followed by /, ? or &
line 130:
E10: \ should be followed by /, ? or &
line 131:
E10: \ should be followed by /, ? or &
line 132:
E10: \ should be followed by /, ? or &
line 133:
E10: \ should be followed by /, ? or &
line 134:
E10: \ should be followed by /, ? or &
line 135:
E10: \ should be followed by /, ? or &
line 136:
E10: \ should be followed by /, ? or &
line 137:
E10: \ should be followed by /, ? or &
line 138:
E10: \ should be followed by /, ? or &
line 139:
E10: \ should be followed by /, ? or &
Press ENTER or type command to continue <-- indefinitely blocks

The exact reason why this is not usually observed, is typically, when vim has a ~/.vimrc, 'C' mode is disabled by default. However, that property is *not* granted to -u

http://vimhelp.appspot.com/message.txt.html#E10

http://vimhelp.appspot.com/options.txt.html#%27cpoptions%27

http://vimhelp.appspot.com/options.txt.html#%27compatible%27 # <-- take special note of the special casing of -u

http://vimhelp.appspot.com/starting.txt.html#compatible-default

This effectively means the majority of users using vim are using it in nocompatible mode, and as such, most plugins etc are written under that assumption, and are poorly tested without compatible mode.

Each case of a plugin failing to guard against this is still a bug in the plugin in question, but requires every plugin to work around it, which, not all do.

In essence, this test turns itself into a "Do you have any vim plugins not written to work without compatibility mode" test, instead of a "Is Perl-Tags broken" test.

The easiest most obvious fix is put

:set nocp

in the top of _vimrc, which will give much better average results.

Sat Nov 28 13:19:21 2015 osfameron [...] cpan.org - Correspondence added

On Thu Jul 16 07:16:05 2015, KENTNL wrote: Show quoted text

> vim -u _vimrc implies that the default, "nocp" is disabled. > > Under compatibility mode, line continuations are disabled. > > Thus, the absence of a ":set nocp" in this vimrc causes any plugins > that vim > loads using line continuations to fail.

... Show quoted text

> In essence, this test turns itself into a "Do you have any vim plugins > not > written to work without compatibility mode" test, instead of a "Is > Perl-Tags > broken" test. > > The easiest most obvious fix is put > :set nocp > in the top of _vimrc, which will give much better average results.

Oh, interesting! I had probably thought by setting `-u t/_vimrc` it wouldn't load plugins. But I guess $VIMRUNTIMEPATH is still as before. I wonder if running with `--noplugin` is a sensible thing to do here. Will have a look.

Sat Nov 28 13:19:21 2015 The RT System itself - Status changed from 'new' to 'open'

Sat Nov 28 15:17:52 2015 osfameron [...] cpan.org - Correspondence added

On Sat Nov 28 13:19:21 2015, OSFAMERON wrote: Show quoted text

> On Thu Jul 16 07:16:05 2015, KENTNL wrote:

> > vim -u _vimrc implies that the default, "nocp" is disabled. > > > > Under compatibility mode, line continuations are disabled.

>

> > In essence, this test turns itself into a "Do you have any vim > > plugins not written to work without compatibility mode" test, instead of a "Is > > Perl-Tags broken" test.

Hi. I can't replicate this issue, having installed vimscripts/Briofita with Vundle (Vim 7.3, perl 5.22). Can you tell me more about your setup to help me replicate the issue?

Sat Nov 28 15:22:04 2015 osfameron [...] cpan.org - Correspondence added

On Sat Nov 28 15:17:52 2015, OSFAMERON wrote: Show quoted text

> Hi. I can't replicate this issue, having installed > vimscripts/Briofita with Vundle (Vim 7.3, perl 5.22). Can you tell me > more about your setup to help me replicate the issue?

Ah, I see - Vundle is an extra layer around loading plugins. You have the briofita plugin directly in $VIMDIR/plugins/ I can replicate the behaviour, and see that adding --noplugin should fix it. Thanks for the report!

Sat Nov 28 15:30:57 2015 osfameron [...] cpan.org - Correspondence added

On Sat Nov 28 15:22:04 2015, OSFAMERON wrote: Show quoted text

> On Sat Nov 28 15:17:52 2015, OSFAMERON wrote:

> > Hi. I can't replicate this issue, having installed > > vimscripts/Briofita with Vundle (Vim 7.3, perl 5.22). Can you tell > > me > > more about your setup to help me replicate the issue?

> > Ah, I see - Vundle is an extra layer around loading plugins. You have > the briofita plugin directly in $VIMDIR/plugins/ > > I can replicate the behaviour, and see that adding --noplugin should > fix it. Thanks for the report!

hmm, that said, though I can replicate by manually calling: PERL5LIB=$PERL5LIB:lib/ vim -u t/_vimrc Actually running t/05_vim.t doesn't fail for me. So I'll have no way of knowing if --noplugin fixes it for your case too. Meh.

Sat Mar 19 00:28:38 2016 KENTNL [...] cpan.org - Correspondence added

On 2015-11-29 09:30:57, OSFAMERON wrote:
> On Sat Nov 28 15:22:04 2015, OSFAMERON wrote:
> > On Sat Nov 28 15:17:52 2015, OSFAMERON wrote:
> > > Hi. I can't replicate this issue, having installed
> > > vimscripts/Briofita with Vundle (Vim 7.3, perl 5.22). Can you tell
> > > me
> > > more about your setup to help me replicate the issue?
> >
> > Ah, I see - Vundle is an extra layer around loading plugins. You
> > have
> > the briofita plugin directly in $VIMDIR/plugins/
> >
> > I can replicate the behaviour, and see that adding --noplugin should
> > fix it. Thanks for the report!
>
> hmm, that said, though I can replicate by manually calling:
>
> PERL5LIB=$PERL5LIB:lib/ vim -u t/_vimrc
>
> Actually running t/05_vim.t doesn't fail for me. So I'll have no way
> of knowing if --noplugin fixes it for your case too. Meh.

Sorry for the delay.

Locally patching the vim test file to use --noplugin does indeed circumvent this bug.

Subject:

vim_noplugin.patch

diff -Naur Perl-Tags-0.32/t/05_vim.t Perl-Tags-0.32b/t/05_vim.t --- Perl-Tags-0.32/t/05_vim.t 2014-05-11 12:11:34.000000000 +0000 +++ Perl-Tags-0.32b/t/05_vim.t 2016-03-19 04:25:04.831985917 +0000 @@ -37,6 +37,7 @@ system vim => -u => 't/_vimrc', # use our vimrc to add Perl::Tags settings etc. -S => 't/session.vim', # use our session file to make modfications to file + '--noplugin', # Don't load 3rd party plugins which can break '-n', # don't use swapfile $temp;