Re: modern regexes in emacs

[Alan Mackenzie <acm@muc.de>]

Hello, Eli.

On Fri, Feb 15, 2019 at 22:00:53 +0200, Eli Zaretskii wrote:
> > Date: Fri, 15 Feb 2019 19:14:47 +0000
> > Cc: perry@piermont.com, mattiase@acm.org, lokedhs@gmail.com,
> >   emacs-devel@gnu.org, philippe.vaucher@gmail.com, jaygkamat@gmail.com
> > From: Alan Mackenzie <acm@muc.de>

> > > > I suggest we retain our current regexp notation, together with compatible
> > > > tools, as the sole way of writing regexps in Emacs.  This notation is not
> > > > all that bad, and it is thoroughly documented and well tested.  It's the
> > > > approach which will cause the least confusion.  It works.

> > > I proposed to have a separate set of functions that will accept PCRE
> > > syntax.  That would allow everyone to have what they want: you to use
> > > the "classic" regexps, and those who want PCRE to have that.  Where's
> > > the problem with that?

> > This will end up with a mixture of the two incompatible styles of regexp
> > in the Emacs sources.  I can see there being such a mixture even within
> > single source files.  This will be confusing to everybody, particularly
> > to beginners.

> How is that different from having rx.el?

rx.el is fully compatible with standard regexps, and can be viewed as a
tool to construct them.

> And how is that different from having pcase.el, which invents a whole
> new sub-language on top of Lisp?

I fear it might not be.  I don't think pcase.el was a good addition to
Emacs.

> Etc. etc. -- that ship has already sailed.

No, just because we have several questionable extensions to Emacs Lisp
doesn't mean we shouldn't be careful when considering further extensions.

> IMO, we'd be silly (let alone look and sound silly) to try to stop
> this.  The net result will be an unbundled package which everyone will
> use, while we bury our heads in the sand.

Maybe you're right.  But nobody in the thread before me had brought up
the disadvantages of the proposal, so I did.

To implement a full PCRE inside Emacs Lisp will involve extending it to
handle Emacs specific elements (such as \s<character>), and thus closely
tying it with syntax.c, etc.  "Trying to stop" the proposal may need
little more than not actively supporting it.

Maybe it won't be as bad as I foresee.  There are "but"s, though.

-- 
Alan Mackenzie (Nuremberg, Germany).