[vim/vim] Automatic regular expression engine selection matches incorrectly on long line (#867)

83 views
Skip to first unread message

fritzophrenic

unread,
Jun 15, 2016, 11:56:38 AM6/15/16
to vim/vim

Using the following regular expression:

\%(|\u.*\)\@<=[^|\t]\+$

I get a match in this line with default settings, or when I force automatic selection with \%#=0:

        xxxxxxxxxxxx    xxxx xxxxxx xxxxxxx x xxxxxxxxx xx xxxxxx xxxxxx xxxxx xxxxxxx xx xxxx xxxxxxxx xxxx xxxxxxxxxxx xxx xxxxxxx xxxxxxxxx xx xxxxxx xx xxxxxxx xxxxxxxxxxxxxxxx xxxxxxxxx  xxx xxxxxxxx xxxxxxxxx xxxx xxx xxxx xxx xxx xxxxx xxxxxxxxxxxx xxxx xxxxxxxxx xxxxxxxxxxx xx xxxxx xxx xxxxxxxx xxxxxx xxx xxx xxxxxxxxx xxxxxxx x xxxxxxxxx xx xxxxxx xxxxxxx  xxxxxxxxxxxxxxxxxx xxxxxxx xxxxxxx xxx xxx xxxxxxxx xxxxxxx  xxxx xxx xxxxxx xxxxx xxxxx xx xxxxxx xxxxxxx xxx xxxxxxxxxxxx xxxx xxxxxxxxx xxxxxx xxxxxx xxxxx xxx xxxxxxx xxxxxxxxxxxxxxxx xxxxxxxxx  xxxxxxxxxx xxxx xx xxxxxxxx xxx xxxxxxxxxxx xxxxx

However, if I force the engine to either 1 or 2, there is no match, as expected.

Tested in 7.4.1862, with patch 1848 reverted. I will try again in a more recent Vim when I get time to compile it later today, but I took a quick look at the patch list and didn't see anything that appears relevant since then.


You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub, or mute the thread.

fritzophrenic

unread,
Jun 15, 2016, 5:39:48 PM6/15/16
to vim/vim

Confirmed, this also affects 7.4.1940, both on 64-bit Windows 7, and on Solaris. Setting the 'regexpengine' to either 1 or 2 also causes the pattern to correctly not match.

Christian Brabandt

unread,
Jun 16, 2016, 1:57:28 AM6/16/16
to reply+00b1d19846fe0c9681d136bdc6bc0e3b10932de...@reply.github.com, vim/vim, vim...@googlegroups.com
Am 2016-06-15 23:39, schrieb fritzophrenic:
> Confirmed, this also affects 7.4.1940, both on 64-bit Windows 7, and
> on Solaris. Setting the 'regexpengine' to either 1 or 2 also causes
> the pattern to correctly not match.
>

Can you please set verbose before searching?

I wonder if this happens, because the NFA engine stops because it
returns NFA_TOO_EXPENSIVE
and then the retry with the old engine is somehow confused? There should
be a message
about switching the engine, if verbose is set.

Best,
Christian

fritzophrenic

unread,
Jun 16, 2016, 10:12:07 AM6/16/16
to vim/vim, vim-dev ML, Comment

Can you please set verbose before searching?

I did "gvim -N -u NONE -i NONE" then ":set verbose=15". Searching for "\%(|\u.*)\@<=[^|\t]+$" in a long line with no uppercase characters still matches, and I get no messages at all.

I wonder if this happens, because the NFA engine stops because it returns NFA_TOO_EXPENSIVE and then the retry with the old engine is somehow confused?

I don't think so (and I guess I proved it with the verbose setting, unless I did that wrong), because I can force the new engine with \%#=2 or by setting 'regexpengine', and the pattern works as expected.


You are receiving this because you commented.

Christian Brabandt

unread,
Jun 28, 2016, 2:14:35 PM6/28/16
to reply+00b1d198fdda749efe01abe0a04722386260154...@reply.github.com, vim-dev
On Do, 16 Jun 2016, fritzophrenic wrote:

> > Can you please set verbose before searching?
>
> I did "gvim -N -u NONE -i NONE" then ":set verbose=15". Searching for "\%(|\u.*\)\@<=[^|\t]\+$" in a long line with no uppercase characters still matches, and I get no messages at all.
>
> > I wonder if this happens, because the NFA engine stops because it returns NFA_TOO_EXPENSIVE and then the retry with the old engine is somehow confused?
>
> I don't think so (and I guess I proved it with the verbose setting, unless I did that wrong), because I can force the new engine with \%#=2 or by setting 'regexpengine', and the pattern works as expected.

Okay, I checked the problem. My suspicion was correct, that patch
7.4.494 causes this problem, because after recursive_regmatch() returns
NFA_TOO_EXPENSIVE nfa_listid will be restored from save_nfa_listid and
then the exit condition in nfa_regmatch does not match anymore.

Attached is a patch, including a test.
(attachment won't be visible in github, see the thread
https://groups.google.com/d/msg/vim_dev/BE0ISqcD3aI/ZGeOMrFQJgAJ for the
patch)

Best,
Christian
--
Die beste kurzfristige Erfolgsmeldung ist das Mienenspiel deines
Bankdirektors.
-- Helmar Nahr
0001-do-not-restore-nfa_listid-state-when-pattern-too-exp.patch

Bram Moolenaar

unread,
Jun 28, 2016, 4:39:50 PM6/28/16
to vim/vim, vim-dev ML, Comment

Closed #867 via 6747fab.


You are receiving this because you commented.

Bram Moolenaar

unread,
Jun 28, 2016, 4:39:53 PM6/28/16
to Christian Brabandt, reply+00b1d198fdda749efe01abe0a04722386260154...@reply.github.com, vim-dev
Glad you could locate and fix it!

--
hundred-and-one symptoms of being an internet addict:
163. You go outside for the fresh air (at -30 degrees) but open the
window first to hear new mail arrive.

/// 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 ///
Message has been deleted

vim-dev ML

unread,
Oct 19, 2016, 1:16:05 PM10/19/16
to vim/vim, vim-dev ML, Your activity
Hello,

I saw you last achievements, and I think you need to keep up the good work! Here is some helpful information for you <http://rush.attorneysearchgroup.com/e4xnyb>

Wishes, paul
Reply all
Reply to author
Forward
0 new messages