unofficial mirror of bug-gnu-emacs@gnu.org 
 help / color / mirror / code / Atom feed
From: Drew Adams <drew.adams@oracle.com>
To: rms@gnu.org
Cc: mattiase@acm.org, 36496@debbugs.gnu.org
Subject: bug#36496: [PATCH] Describe the rx notation in the lisp manual
Date: Sun, 7 Jul 2019 17:56:31 -0700 (PDT)	[thread overview]
Message-ID: <2a29fbfb-7e94-4022-bbde-42d8b9f90fc8@default> (raw)
In-Reply-To: <E1hkGwG-0005Ic-6y@fencepost.gnu.org>

>   > would be great if you could invoke a command on a
>   > regexp (e.g. a regexp string in code) and have an
>   > equivalent `rx' expression pop up, for inspection
>   > and understanding.
> 
> I agree.  That would make rx much more convenient for people who like
> the shortness of some regexps.

It would also help someone understand a complex regexp.

It could also help someone learn about regexps by, in
effect analyzing them (on demand).

It would also be good to be able to select _part_ of a
complex regexp - a part that is itself a valid regexp,
and use such an inspection command on just that part,
to show what `rx' it corresponds to.  IOW, select some
text, not necessarily a string, and (if its a valid
regexp) get its `rx' form.

> It could be part of Lisp mode, so you
> could use this on a regexp constant in a source file.
> 
> I suspect that the long-windedness of rx input is a substantial
> deterrent to its use.  It may be better for complex patterns but worse
> for simple ones.
> 
>   > It would be nice to be able to have only the result
>   > of `rx' in the code and be able to get its `rx'
>   > expression on demand.
> 
> I think it would be clearer, usually, for Lisp source to have the rx
> form.  That would help people get used to rx.  For complex patterns,
> the rx form is easier to understand and change.
> 
> WHat would people think of making all the functions that want a regexp
> accept an rx input equivalently?  If the arg is not a string, treat it
> as rx format.

Do you mean they'd accept a quoted `rx' form (list)?
What would a use case be - as opposed to accepting
the result of macro-expanding such a form?  Assuming
there's good use case, maybe so. 

[But there may be some functions that already have a
(different) interpretation of a list value for the
same arg that could alternatively be a regexp string.
(So maybe not "all" such functions.)]

> Compilation could convert a constant non-string, for
> such args, to a regexp string.

Same question as above, about the use case for a
quoted `rx'-form arg (versus macro-expanding it to
provide a regexp string arg).

Even assuming such a use case, should the compiler
assume that _every_ such list arg should be compiled
to a regexp string?

And wouldn't such compile-time conversion just
amount to macro-expanding it?  I guess I might be
missing your point/suggestion.

> Commands that read a regexp using the minibuffer could offer a key to
> say that you are entering rx format.

Sounds good to me.

> The only problem is, which key would it be?

Some non-repeatable key.  Some key that can't be
used (by default) to edit minibuffer text.  Maybe
something like `C-x x'?





  reply	other threads:[~2019-07-08  0:56 UTC|newest]

Thread overview: 26+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-07-04 12:13 bug#36496: [PATCH] Describe the rx notation in the lisp manual Mattias Engdegård
2019-07-04 14:59 ` Drew Adams
2019-07-04 16:28 ` Eli Zaretskii
2019-07-05 14:13   ` Mattias Engdegård
2019-07-06  9:08     ` Eli Zaretskii
2019-07-06 11:33       ` Mattias Engdegård
2019-07-06 11:41         ` Eli Zaretskii
2019-07-06 18:56           ` Mattias Engdegård
2019-07-06 19:10             ` Eli Zaretskii
2019-07-06 19:45               ` Mattias Engdegård
2019-07-07  2:29                 ` Eli Zaretskii
2019-07-07 11:31                   ` Mattias Engdegård
2019-07-07 14:33                     ` Eli Zaretskii
2022-04-25 15:12                     ` Lars Ingebrigtsen
2019-07-06 19:12             ` Noam Postavsky
2019-07-06 11:59         ` Noam Postavsky
2019-07-06 23:56         ` Richard Stallman
2019-07-06  0:10   ` Richard Stallman
2019-07-06  6:47     ` Eli Zaretskii
2019-07-06 23:59       ` Richard Stallman
2019-07-07  0:36         ` Drew Adams
2019-07-07 23:51           ` Richard Stallman
2019-07-08  0:56             ` Drew Adams [this message]
2019-07-08 23:46               ` Richard Stallman
2019-07-09  0:19                 ` Drew Adams
2019-07-08 23:44             ` Richard Stallman

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=2a29fbfb-7e94-4022-bbde-42d8b9f90fc8@default \
    --to=drew.adams@oracle.com \
    --cc=36496@debbugs.gnu.org \
    --cc=mattiase@acm.org \
    --cc=rms@gnu.org \
    /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).