Re: will we ever have zero width assertions in regexps?

[Stefan Monnier <monnier@iro.umontreal.ca>]

>> A typical case could look something like "foo *(.*?) *bar". when
>> matching "foo ..<many space>.. baZ".

> No, this is a polynomial-time problem.  My optimization does nothing
> for such cases.  And I do not think such a REx would provide any
> problem in real life - unless you have many hundreds of consecutive
> spaces.

Such problems tend to show up (in hard to fix ways that is) with regexps
that are built in pieces (e.g. by combining existing regexps like
comment-start-skip and paragraph-start or things like that).

And yes, these tend to work just fine in practice, which is why they end
up in real code, and then a couple years later someone complains that
Emacs freezes when he opens his funny file with some odd long line.

> (And unless Emacs' REx engine is particularly slow per OPCODE.)

Emacs's REx engine isn't particularly fast, I think, but I don't think
it's the problem.

> But I start to see the difference - it is in usage scenarios.

Probably.

> Many Perl REx matches are done "per-line", not "per-file".

That's one difference.  Another is that many regexps are used all the
time without the user explicitly asking for it, and on text which we
assume takes a particular shape, even though it may take a completely
different form (e.g. regexps used for the *compile* buffer).

> match-with-continuation.  An interesting idea.  I already implemented
> it for Perl (to support (??{}), but it is not exposed to the user.
> Would one want this in non-interactive situations?

I can't think of interactive uses, but I'd like to try and use it for
to let font-lock find elements that span several lines, even when it
works one-line-at-a-time.


        Stefan