Regeression in RE ("\%>")somewhere after 7.4.560

83 views
Skip to first unread message

Axel Bender

unread,
Jan 17, 2015, 1:52:46 PM1/17/15
to vim...@googlegroups.com
1) Open the attached file "test.txt".
2) set ts=80
3) /\%>80vGesamtausabe

Contrary to the behavior in 560 (Windows 7, MinGW64), only the term "Gesamtausgabe" in the second line is marked.
test.txt

Axel Bender

unread,
Jan 17, 2015, 1:55:01 PM1/17/15
to vim...@googlegroups.com
Addendum: Typo: Gesamtausabe => Gesamtausgabe

John Little

unread,
Jan 17, 2015, 10:43:39 PM1/17/15
to vim...@googlegroups.com
I see this in 7.4.580, linux amd64. In fact, the \%>Nv atom looks quite broken, given the line, and vim -u NONE -N:

abcdefgh

\%>2vc and \%2vd work, but \%>2ve does not. More generally, \%>Nv does not match beyond N + 2, and it used to.

Regards, John Little

Christian Brabandt

unread,
Jan 18, 2015, 8:32:29 AM1/18/15
to vim...@googlegroups.com
Hi Axel!

On Sa, 17 Jan 2015, Axel Bender wrote:

> 1) Open the attached file "test.txt".
> 2) set ts=80
> 3) /\%>80vGesamtausabe

I apologize for causing this.

Here is a fix (including a test).

Best,
Christian
--
Man braucht nicht geistreich zu sein, um zu beweisen, daß man begabt
ist. Aber man braucht viel Geist, um zu verbergen, daß man keine
Begabung hat.
-- Marcel Achard
vcol_regression.diff

Bram Moolenaar

unread,
Jan 18, 2015, 10:22:14 AM1/18/15
to Christian Brabandt, vim...@googlegroups.com

Christian Brabandt wrote:

> Hi Axel!
>
> On Sa, 17 Jan 2015, Axel Bender wrote:
>
> > 1) Open the attached file "test.txt".
> > 2) set ts=80
> > 3) /\%>80vGesamtausabe
>
> I apologize for causing this.
>
> Here is a fix (including a test).

Thanks. It fixes the problem reported, but using vcol_prev won't work
properly. If the engine tries this state at another position, or
another state, it will have the wrong value.

Not sure how to remove vcol_prev without making it slow again.
A rough guess is to multiply the column with 'tabstop'.
Let me do that for now.

--
From "know your smileys":
:-F Bucktoothed vampire with one tooth missing

/// Bram Moolenaar -- Br...@Moolenaar.net -- http://www.Moolenaar.net \\\
/// sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\
\\\ an exciting new programming language -- http://www.Zimbu.org ///
\\\ help me help AIDS victims -- http://ICCF-Holland.org ///

Bram Moolenaar

unread,
Jan 20, 2015, 11:56:29 AM1/20/15
to Christian Brabandt, vim...@googlegroups.com

I wrote:

> Christian Brabandt wrote:
>
> > Hi Axel!
> >
> > On Sa, 17 Jan 2015, Axel Bender wrote:
> >
> > > 1) Open the attached file "test.txt".
> > > 2) set ts=80
> > > 3) /\%>80vGesamtausabe
> >
> > I apologize for causing this.
> >
> > Here is a fix (including a test).
>
> Thanks. It fixes the problem reported, but using vcol_prev won't work
> properly. If the engine tries this state at another position, or
> another state, it will have the wrong value.
>
> Not sure how to remove vcol_prev without making it slow again.
> A rough guess is to multiply the column with 'tabstop'.
> Let me do that for now.

Thinking about this again: It should be OK to store the column and the
computed virtual column. These do not depend on the RE state. When
trying several states at the same position the virtual column will be
computed only once. And when the column is higher than the cached
column, we know the virtual column is also higher than the cached
virtual column. That should help avoid useless calls to
win_linetabsize() while still being accurate, instead of the wild guess
using 'tabsize'.

Christian, do you think you could work on this? And write a test.

--
From "know your smileys":
<|-) Chinese
<|-( Chinese and doesn't like these kind of jokes

Christian Brabandt

unread,
Jan 21, 2015, 1:58:38 PM1/21/15
to vim...@googlegroups.com
Hi Bram!

On Di, 20 Jan 2015, Bram Moolenaar wrote:

> Thinking about this again: It should be OK to store the column and the
> computed virtual column. These do not depend on the RE state. When
> trying several states at the same position the virtual column will be
> computed only once. And when the column is higher than the cached
> column, we know the virtual column is also higher than the cached
> virtual column. That should help avoid useless calls to
> win_linetabsize() while still being accurate, instead of the wild guess
> using 'tabsize'.

We would also need this for the old engine, don't we?

>
> Christian, do you think you could work on this? And write a test.

I'd like to, but I do not understand the NFA engine good enough to do
this.

Best,
Christian
--
Tausch nicht das Leben gegen den Traum. Besiegen kann man nur die
Wirklichkeit.
-- Lucius Annaeus Seneca (4-65 n.Chr.)
Reply all
Reply to author
Forward
0 new messages