bug-gnu-emacs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#36237: Support (rx (and (regexp EXPR) (regexp-quote EXPR)))


From: Noam Postavsky
Subject: bug#36237: Support (rx (and (regexp EXPR) (regexp-quote EXPR)))
Date: Sun, 16 Jun 2019 08:25:46 -0400
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/26.2 (gnu/linux)

> [ BTW, please use "--" for rx-compile-to-lisp since I believe it's
>   internal.  ]

I'm not sure that it is, e.g., python-rx might bind it too (if it
weren't for the fact that python.el needs to maintain backwards
compatibility with older Emacs).

> What do regexp and regexp-quote do in rx-to-string?

regexp does exactly what it did before, i.e., it accepts only a constant
string.  Likewise regexp-quote accepts only a constant string, which
makes it pointless to use in rx-to-string (just use a plain STRING
directly), but I didn't disallow it.

Hmm, I think I had meant to update rx-to-string's docstring, but forgot
about it.

>> - A more suitable name is needed; `regexp-quote' makes no sense at all in
>> the context of rx. What about `literal'? For simplicity, I'm proceeding with
>> that name below.
>
> I'll let others figure that one out.

Probably `literal' makes sense.  I originally used regexp-quote, just
because I was thinking of it as a short form of

    (rx (regexp (regexp-quote EXPR)))

>> - What is now the correct way of including a compile-time regexp expression,
>> such as a defconst? (regexp (eval-when-compile EXPR))? Still a mouthful, but
>> perhaps outside the scope of this bug.

Oh, hmm.  That might be a reason to keep using `eval'.

> FWIW, I have the impression that in most cases where this could be
> useful, a better solution would be to provide something like
> `rx-defmacro` and/or `rx-macrolet`.

I guess that could replace the "old crusty" rx-constituents thing too.

>> I have: I'm sitting on a full rewrite, code-named `ry'. It's shorter,
>> much cleaner, and about twice as fast (usually more). The only thing
>> still missing is compatibility with the old crusty `rx-constituents'
>> extension mechanism.
>> 
>> The plan was to replace rx with ry entirely when complete.

How far away is this?  Would it make sense to delay this bug until "ry"
comes in?





reply via email to

[Prev in Thread] Current Thread [Next in Thread]