[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: modern regexes in emacs

From: Alan Mackenzie
Subject: Re: modern regexes in emacs
Date: Fri, 15 Feb 2019 20:40:38 +0000
User-agent: Mutt/1.10.1 (2018-07-13)

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: address@hidden, address@hidden, address@hidden,
> >   address@hidden, address@hidden, address@hidden
> > From: Alan Mackenzie <address@hidden>

> > > > 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

> 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).

reply via email to

[Prev in Thread] Current Thread [Next in Thread]