[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
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).
- Re: modern regexes in emacs, (continued)
- Re: modern regexes in emacs, Elias Mårtenson, 2019/02/25
- Re: modern regexes in emacs, Mattias Engdegård, 2019/02/26
- Re: modern regexes in emacs, Perry E. Metzger, 2019/02/15
- Re: modern regexes in emacs, Juri Linkov, 2019/02/17
- Re: modern regexes in emacs, Stefan Monnier, 2019/02/17
- Re: modern regexes in emacs, Clément Pit-Claudel, 2019/02/15
- Re: modern regexes in emacs, Eli Zaretskii, 2019/02/15
- Re: modern regexes in emacs, Clément Pit-Claudel, 2019/02/15
- Re: modern regexes in emacs, Alan Mackenzie, 2019/02/15
- Re: modern regexes in emacs, Eli Zaretskii, 2019/02/15
- Re: modern regexes in emacs,
Alan Mackenzie <=
- Re: modern regexes in emacs, Perry E. Metzger, 2019/02/15
- Re: modern regexes in emacs, Clément Pit-Claudel, 2019/02/15
- Re: modern regexes in emacs, Stefan Monnier, 2019/02/15
- Re: modern regexes in emacs, Van L, 2019/02/19
- Re: modern regexes in emacs, Stefan Monnier, 2019/02/17
- Re: modern regexes in emacs, Philippe Vaucher, 2019/02/18
- Re: modern regexes in emacs, Mattias Engdegård, 2019/02/18