[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: will we ever have zero width assertions in regexps?
From: |
Ilya Zakharevich |
Subject: |
Re: will we ever have zero width assertions in regexps? |
Date: |
Tue, 8 Feb 2011 22:41:18 +0000 (UTC) |
User-agent: |
slrn/0.9.8.1pl1 (Linux) |
On 2011-02-07, Stefan Monnier <monnier@iro.umontreal.ca> wrote:
>> Hmm, I thought about a different scenario: if the bit is set, then one
>> switches to a DIFFERENT REx designed for a multi-line case. Otherwise
>> why not just run it against the rest of the buffer, instead of
>> one-line?
>
> Because we don't want to match those regexps against the whole buffer
> every time the buffer is modified (the buffer may be large).
I think there is some confusion here: I did not want to mean that you
run "another REx" via re-search(), but via looking-at() at the
corresponding position... Essentially: do you want the REx to start
match on the current line, or end match on the current line?
Or maybe you mean a different thing, and
WANT e.g. [^a-z] to actually "mean" [^a-z\n] ? (So only an explicit
non-negated \n in a REx may match \n in a buffer?)
> BTW, another reason to want a non-backtracking matcher can be seen in
> the recent thread "Stack overflow in regexp matcher".
I think this is a red herring. Try to stack-overflow the Perl
matcher... (Possible, but one must be very malicious to hit these
situations.)
Ilya