On Monday, January 6, 2014 12:59:31 PM UTC-6, Brett Stahlman wrote: > On Monday, January 6, 2014 12:18:17 AM UTC-6, Bram Moolenaar wrote: > > Brett Stahlman wrote: > > > > > > > > > Possible bugs in new regex engine involving \@> and \? > > > > > > > > > > Using the following line of text... > > > > > 0123456789 > > > > > > > > > > ...run the following two :substitute commands with both old and new regex > > > engine, and notice the differences... > > > > > > > > > > s/\(01\)\(23\)\@>\(.*\)/--\1--\2--\3/ > > > > > Old (\%=1) > > > > > --01--23--456789 > > > > > New (\%=2) > > > > > ----23--456789 > > > > > > > > > > s/\(01\)\(23\d\@=\)\?\(.*\)/--\1--\2--\3/ > > > > > Old (\%=1) > > > > > --01--23--456789 > > > > > New (\%=2) > > > > > --01----23456789 > > > > > > > > > > Note: The \d\@= in the second example could be replaced with other > > > > > matching zero-width assertions (e.g., \%v) without changing the > > > > > results. > > > > > > > > I'll add a remark in the todo list. Thanks for the examples. > > > > Can you simplify them further? Can you also see the effect with only a > > > > search? > > No problem. How about this? > s/\(1\d\@=\)\?\(.*\)/\1:\2/ > > Executed on the following line... > 123 > ...the new regexp engine produces... > :123 > > Note that if I remove the * from the second capturing group, the substitute > works as expected. It's as though the \? is not behaving greedily when it's > followed by something capable of eating what it leaves behind.
The behavior isn't limited to \?. Other optional quantifiers (e.g., *) appear to behave the same. Moreover, it appears that any type of assertion within the group will work (though the assertion must come after the piece that matches, not before). Here are some other examples to illustrate: Note: These patterns should match at the "2" in "123". \(11\@<=\)*\zs\d* \(11\@!\)*\zs\d* Note: This one works as expected! \(2\@!1\)*\zs\d* Note: If you remove the * at the end of the pattern, all examples work correctly! It's as though the presence of the zero-width assertion within the first group causes the group's quantifier to behave non-greedily, if and only if there's a subsequent greedy quantifier capable of consuming whatever the first quantifier leaves. Thanks, Brett Stahlman > > I do see the same behavior in a search: in particular, incremental searching > highlights "123" for the following pattern: > \(1\d\@=\)\?\zs\(.*\) > With the old regexp engine, only "23" is highlighted, as expected. > > Thanks, > Brett Stahlman > > > > > > > > > > -- > > > > Laughing helps. It's like jogging on the inside. > > > > > > > > /// Bram Moolenaar -- [email protected] -- 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 /// -- -- You received this message from the "vim_use" maillist. Do not top-post! Type your reply below the text you are replying to. For more information, visit http://www.vim.org/maillist.php --- You received this message because you are subscribed to the Google Groups "vim_use" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/groups/opt_out.
