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: Mon, 8 Jul 2019 17:19:32 -0700 (PDT) [thread overview]
Message-ID: <bfe627a2-e15c-4a48-af50-abe60d8f3fe6@default> (raw)
In-Reply-To: <E1hkdLB-0007Bx-2K@fencepost.gnu.org>
> > 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.
>
> Quoting is a little more brief than writing (rx ...).
Sorry, but I don't really understand. I know little
about `rx'.
> > [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.)]
>
> Are there any? If so, it would be desirable to change them.
I was responding to this from you:
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. Compilation could convert a constant non-string, for
such args, to a regexp string.
I see now that you said "an rx input", so presumably
not just a list as arg but a list with car `rx'. I
was thinking you meant just a list. I'd bet there
are some functions that accept an arg that can be a
(nonempty) list or a string, and maybe even a regexp
string. If there are then some minor adjustment
could be called for; that's all.
> > Even assuming such a use case, should the compiler
> > assume that _every_ such list arg should be compiled
> > to a regexp string?
>
> Why not? Is there any case in which it would be better
> to translate the rx to a regexp at run time?
I think I misunderstood you, and might still.
Still, there's a difference between passing
(quote SOME-MACRO-SEXP) as arg and passing
SOME-MACRO-SEXP. We have `quote' for a reason.
If you want macro-expansion at compile time
why wouldn't you just pass (rx...) as the arg,
instead of (quote (rx...))?
But you know all this better than I, so no doubt
I'm just missing your point - in which case feel
free to ignore.
> > > 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'?
>
> Is there any reasonable one-character key?
There are lots of 1-char keys that are not defined
in a minibuffer keymap by default. And perhaps
even some that are defined there by default but
that aren't useful for reading a regexp (so could
be co-opted when reading regexp input, if needed).
As just one example, `M-R' is not defined (`M-r'
is). `M-R' is `move-to-window-line-top-bottom',
which isn't so useful in a minibuffer window.
(It is a repeatable key, BTW, and its global
binding is a repeatable command. But that command
isn't very useful in the minibuffer.)
next prev parent reply other threads:[~2019-07-09 0:19 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
2019-07-08 23:46 ` Richard Stallman
2019-07-09 0:19 ` Drew Adams [this message]
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=bfe627a2-e15c-4a48-af50-abe60d8f3fe6@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).