[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: rx and rx-to-string handle (regexp VAR) differently
From: |
Kévin Le Gouguec |
Subject: |
Re: rx and rx-to-string handle (regexp VAR) differently |
Date: |
Fri, 09 Jun 2023 08:35:04 +0200 |
User-agent: |
Gnus/5.13 (Gnus v5.13) |
Eli Zaretskii <eliz@gnu.org> writes:
>> From: Kévin Le Gouguec <kevin.legouguec@gmail.com>
>> Date: Thu, 08 Jun 2023 23:44:07 +0200
>>
>> Is there a bug to file here, or have I missed something in the
>> documentation that explains why rx can work with (regexp VAR) but
>> rx-to-string cannot?
>
> FWIW, "Extending Rx" in the ELisp manual says:
>
> • Definitions are only ever expanded in calls to ‘rx’ or
> ‘rx-to-string’, not merely by their presence in definition macros.
>
> So I think this ought to be supported, and you should file a bug:
> either the implementation or the documentation should be fixed.
ACK; will do.
I see that the note in rx-to-string's docstring re. only supporting
literal strings for 'regexp' and 'literal' dates from 2019-06-25
"Support (rx (and (regexp EXPR) (literal EXPR))) (Bug#36237)"
(b59ffd2290f):
(defun rx-to-string (form &optional no-group)
"Parse and produce code for regular expression FORM.
FORM is a regular expression in sexp form.
-NO-GROUP non-nil means don't put shy groups around the result."
+NO-GROUP non-nil means don't put shy groups around the result.
+
+In contrast to the `rx' macro, subforms `literal' and `regexp'
+will not accept non-string arguments, i.e., (literal STRING)
+becomes just a more verbose version of STRING."
I might also give that thread a read to see what prompted this
limitation.