Re: prior work on non-backtracking regex engine?

[Eli Zaretskii]

> From: Helmut Eller <eller.helmut@gmail.com>
> Cc: Ihor Radchenko <yantar92@posteo.net>,  "emacs-devel@gnu.org"
>  <emacs-devel@gnu.org>
> Date: Mon, 08 Apr 2024 14:19:13 +0200
> 
> 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?

The Gnulib regex is basically the glibc regex.

Why Emacs cannot use the glibc code was discussed here (among other
places):

  https://lists.gnu.org/archive/html/emacs-devel/2002-04/msg00084.html

> My guess is that it has something to do with the way Emacs's performs
> case-insensitive matches.

No, it's because Emacs has some unique requirements for regular
expressions.

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

Basically, because no one was interested in merging them (which would
include some macro-ization, so that Emacs could have the features it
needs, while other programs could have those special features compile
to trivial code).  regex-emacs.c started that way, but when glibc and
Gnulib switched to a new engine, they never bothered to keep the
Emacs-specific features we had in the original code.