[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#36496: [PATCH] Describe the rx notation in the lisp manual
From: |
Drew Adams |
Subject: |
bug#36496: [PATCH] Describe the rx notation in the lisp manual |
Date: |
Sun, 7 Jul 2019 17:56:31 -0700 (PDT) |
> > 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'?
bug#36496: [PATCH] Describe the rx notation in the lisp manual, Richard Stallman, 2019/07/05
- bug#36496: [PATCH] Describe the rx notation in the lisp manual, Eli Zaretskii, 2019/07/06
- bug#36496: [PATCH] Describe the rx notation in the lisp manual, Richard Stallman, 2019/07/06
- bug#36496: [PATCH] Describe the rx notation in the lisp manual, Drew Adams, 2019/07/06
- bug#36496: [PATCH] Describe the rx notation in the lisp manual, Richard Stallman, 2019/07/07
- bug#36496: [PATCH] Describe the rx notation in the lisp manual,
Drew Adams <=
- bug#36496: [PATCH] Describe the rx notation in the lisp manual, Richard Stallman, 2019/07/08
- bug#36496: [PATCH] Describe the rx notation in the lisp manual, Drew Adams, 2019/07/08
bug#36496: [PATCH] Describe the rx notation in the lisp manual, Richard Stallman, 2019/07/08