Re: regex.c simplification

["Daniel Colascione" <dancol@dancol.org>]

> Eli Zaretskii wrote:
>> I think we still haven't abandoned the hope of updating to the latest
>> glibc/gnulib versions of regex.c, although I'm not sure how practical
>> these hopes are at this point.
>
> That's been on my list of things to do for ages. I don't know if it'll
> ever get
> done, or even whether it's worth doing.
>
> As far as I know, Emacs is the only package that still uses the "old"
> regex.c
> code derived from pre-2002 glibc. Everybody else has migrated to the "new"
> regex.c code that was contributed to glibc in 2002 and is in Gnulib. So,
> in some
> sense regex.c has already forked; we just haven't made it official.
>
> A complication: src/regex.c is compiled twice, once within lib-src (for
> etags)
> and once within src (for Emacs proper), and the "#if defined emacs" stuff
> in
> src/regex.c matters for this.
>
> If we wanted to make the fork more official, we could simplify src/regex.c
> to
> not worry about lib-src, by having etags use Glibc/Gnulib regex rather
> than
> Emacs regex.

That's probably a good idea. The other approach would be to run etags
inside a real Emacs context somehow, and that seems too complicated.

> That would be easy for me to arrange, if you like.

Thanks.

> While we're on the topic, a couple of more comments about regex code.

The regex API could be a lot better too. It'd be nice to expose the
pattern compilation machinery to lisp as some kind of new pattern pvec
object, then let lisp manage the cache. The nice thing about doing it this
way is that you could transparently support having multiple different
kinds of pattern --- e.g., PEGs, PCRE-syntax REs --- and use them
transparently, since you'd be able to supply a pattern object anywhere you
pass a regex string today.