Re: prior work on non-backtracking regex engine?

[Helmut Eller <eller.helmut@gmail.com>]

On Sun, Apr 07 2024, Danny McClanahan wrote:

> And I was also *super*
> pleased to see that regex-emacs.h itself doesn't expose any dependency
> on the gap buffer or other internal emacs representations (except
> regarding multibyte encoding). So in my amateur evaluation, emacs
> actually seems very well-placed to take advantage of high-performance
> regex engine techniques without any big structural changes.

What's the history of regex-emacs.h?  It seems like in the past it was
regex.h from Gnulib.  That would explain why the regex engine is
relatively well decoupled from the rest.  But it also leads to the
question: why does Emacs no longer use Gnulib's regex engine?

My guess is that it has something to do with the way Emacs's performs
case-insensitive matches.  Another complication may be that Gnulib
doesn't support the non-greedy variants of some operators.

It seems that these days Gnulib uses a DFA based algorithm when possible
and falls back to backtracking for backrefs (and presumably for POSIX
compatible sub-match rules).  So one could argue that Gnulib already has
a lot of what we want and would be the natural place to add a clean API
for the features that Emacs needs.

So does somebody know the details why Gnulib and Emacs went separate
ways in the past?

Helmut