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'?
next prev parent 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).