unofficial mirror of emacs-devel@gnu.org 
 help / color / mirror / code / Atom feed
From: Alan Mackenzie <acm@muc.de>
To: "Perry E. Metzger" <perry@piermont.com>
Cc: "Mattias Engdegård" <mattiase@acm.org>,
	lokedhs@gmail.com, emacs-devel@gnu.org,
	"Philippe Vaucher" <philippe.vaucher@gmail.com>,
	jaygkamat@gmail.com, "Eli Zaretskii" <eliz@gnu.org>
Subject: Re: modern regexes in emacs
Date: Fri, 15 Feb 2019 17:54:05 +0000	[thread overview]
Message-ID: <20190215175405.GA5438@ACM> (raw)
In-Reply-To: <20190215114728.0785e891@jabberwock.cb.piermont.com>

Hello, Perry.

On Fri, Feb 15, 2019 at 11:47:28 -0500, Perry E. Metzger wrote:
> On Fri, 15 Feb 2019 17:24:18 +0100 Mattias Engdegård
> <mattiase@acm.org> wrote:
> > 15 feb. 2019 kl. 15.18 skrev Eli Zaretskii <eliz@gnu.org>:

> > > It should be possible if we introduce new functions for PCRE, or
> > > if we mark PCRE regexps in some special way, like put a special
> > > text property on the string.  

> > It would be easier if those who ask for PCRE would say exactly what
> > they want:

> > (1) The syntax of PCRE -- | () {} instead of \| \(\) \{\} etc --
> > but restricted to the set of features of the Emacs regexp engine.

> Modern syntax is the main one.

Such use of "modern" always gets on my nerves.  "Modern" is not the same
as "good", and likely has a very weak correlation with it.  Why aren't we
all using "modern" editors, for example?

> > (2) The features of PCRE not present in Emacs regexps. Which ones,
> > exactly? Lookbehind assertions? Atomic groups?

> I'm not particularly interested in those.

That would be the sole reason for me for any switch.

> > (3) PCRE for interactive use only.
> > (4) PCRE for general Elisp programming. 

> The old style syntax is repulsive.

I disagree.  But that's not important.  What's important is to have a
standard invariable regexp notation, otherwise confusion and unwanted
unforeseen nastinesses will occur.

> I think we should make it possible to slowly switch over to the syntax
> everyone using regexps has gotten used to over the last 30 years or so.
> BREs in the style Emacs has been using have been obsolete for longer
> than many Emacs users have been alive.

They're not obsolete: they're used in grep, sed, and in Emacs.

There are several different standards for writing regexps, all of
approximately the same age.  None is better than any other (aside from
extra facilities available in some versions).

This seems to me to be the same argument as that proposing that Emacs
should change its key bindings to match those of other programs, because
"everybody" knows those other bindings.

> > Locating and wrapping the places that ask for regexps
> > interactively, such as `query-replace-regexp', would permit the
> > interactive regexp syntax to become a simple user customisation --
> > traditional, PCRE, rx or whatnot. It would be a matter of writing a
> > transformation function, and possibly some syntax highlighting, for
> > each case.

Exactly.  And then we've got 10 to 20 years of confusion, with several
mutually incompatible regexp notations competing for attention in the
same Emacs.  I think this would be a thoroughly bad idea.

> > I wouldn't be surprised if 99% of the requests are really about not
> > having to escape |(){} as metacharacters in interactive use.

> No, that's a lot of my complaint. I can't even remember what the
> correct syntax is half the time.

I don't suffer that difficulty in Emacs (though I sometimes do in grep,
egrep, sed and AWK, all of which have slightly different regexps).  But I
would begin to suffer it if there started to be a mixture of incompatible
regexp notations in Emacs sources.  Let's keep things simple.

> Anyway, I recommend Eli's approach. We create a parallel set of
> modernized syntax functions, and people can slowly adopt them.

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.

> Perry
> -- 
> Perry E. Metzger		perry@piermont.com

-- 
Alan Mackenzie (Nuremberg, Germany).



  reply	other threads:[~2019-02-15 17:54 UTC|newest]

Thread overview: 57+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-06-16 16:37 modern regexes in emacs Perry E. Metzger
2018-06-16 17:45 ` Radon Rosborough
2018-06-16 18:25   ` Perry E. Metzger
2018-06-16 21:01     ` Daniel Colascione
2018-06-16 22:31 ` Jay Kamat
2019-02-09 17:20   ` Philippe Vaucher
2019-02-10  9:39   ` Elias Mårtenson
2019-02-11 22:12     ` Mattias Engdegård
2019-02-15 13:42       ` Philippe Vaucher
2019-02-15 14:10         ` Clément Pit-Claudel
2019-02-15 15:03           ` Philippe Vaucher
2019-02-15 15:13             ` Clément Pit-Claudel
2019-02-15 14:18         ` Eli Zaretskii
2019-02-15 15:28           ` Perry E. Metzger
2019-02-15 16:06             ` Stefan Monnier
2019-02-15 16:24           ` Mattias Engdegård
2019-02-15 16:47             ` Perry E. Metzger
2019-02-15 17:54               ` Alan Mackenzie [this message]
2019-02-15 18:27                 ` Drew Adams
2019-02-15 23:33                   ` Perry E. Metzger
2019-02-16  0:34                     ` Jay Kamat
2019-02-16  1:46                       ` Perry E. Metzger
2019-02-16  2:44                         ` Jay Kamat
2019-02-15 18:36                 ` Eli Zaretskii
2019-02-15 18:43                   ` Mattias Engdegård
2019-02-15 19:48                     ` Eli Zaretskii
2019-02-17  3:17                       ` Richard Stallman
2019-02-25 14:47                         ` Lars Ingebrigtsen
2019-02-25 15:46                           ` Clément Pit-Claudel
2019-02-26  2:57                             ` Richard Stallman
2019-02-26 12:39                               ` Lars Ingebrigtsen
2019-02-26 13:24                                 ` Troy Hinckley
2019-02-26 13:32                                   ` Lars Ingebrigtsen
2019-02-26 14:33                                     ` Andreas Schwab
2019-02-27 12:09                                       ` Mattias Engdegård
2019-02-27 18:18                                         ` Daniel Pittman
2019-02-26 15:29                                 ` Eli Zaretskii
2019-02-27  4:08                                 ` Richard Stallman
2019-02-26  3:47                             ` Elias Mårtenson
2019-02-26 12:00                           ` Mattias Engdegård
2019-02-15 23:35                     ` Perry E. Metzger
2019-02-17 20:01                     ` Juri Linkov
2019-02-18  0:38                       ` Stefan Monnier
2019-02-15 18:46                   ` Clément Pit-Claudel
2019-02-15 19:52                     ` Eli Zaretskii
2019-02-15 20:08                       ` Clément Pit-Claudel
2019-02-15 19:14                   ` Alan Mackenzie
2019-02-15 20:00                     ` Eli Zaretskii
2019-02-15 20:40                       ` Alan Mackenzie
2019-02-15 23:33                   ` Perry E. Metzger
2019-02-15 18:44                 ` Clément Pit-Claudel
2019-02-15 19:37                 ` Stefan Monnier
2019-02-19 12:29                   ` Van L
2019-02-17 20:47         ` Stefan Monnier
2019-02-18  8:40           ` Philippe Vaucher
2019-02-18  8:55           ` Mattias Engdegård
  -- strict thread matches above, loose matches on Subject: below --
2018-06-16 21:33 Jimmy Yuen Ho Wong

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.gnu.org/software/emacs/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20190215175405.GA5438@ACM \
    --to=acm@muc.de \
    --cc=eliz@gnu.org \
    --cc=emacs-devel@gnu.org \
    --cc=jaygkamat@gmail.com \
    --cc=lokedhs@gmail.com \
    --cc=mattiase@acm.org \
    --cc=perry@piermont.com \
    --cc=philippe.vaucher@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).