GNU bug report logs - #36496
[PATCH] Describe the rx notation in the lisp manual

Previous Next

Package: emacs;

Reported by: Mattias Engdegård <mattiase <at> acm.org>

Date: Thu, 4 Jul 2019 12:14:01 UTC

Severity: wishlist

Merged with 31698

Found in version 27.0

Done: Lars Ingebrigtsen <larsi <at> gnus.org>

Bug is archived. No further changes may be made.

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 36496 in the body.
You can then email your comments to 36496 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

View this report as an mbox folder, status mbox, maintainer mbox


Report forwarded to bug-gnu-emacs <at> gnu.org:
bug#36496; Package emacs. (Thu, 04 Jul 2019 12:14:01 GMT) Full text and rfc822 format available.

Acknowledgement sent to Mattias Engdegård <mattiase <at> acm.org>:
New bug report received and forwarded. Copy sent to bug-gnu-emacs <at> gnu.org. (Thu, 04 Jul 2019 12:14:01 GMT) Full text and rfc822 format available.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Mattias Engdegård <mattiase <at> acm.org>
To: bug-gnu-emacs <at> gnu.org
Subject: [PATCH] Describe the rx notation in the lisp manual
Date: Thu, 4 Jul 2019 14:13:26 +0200
[Message part 1 (text/plain, inline)]
The rx notation is useful and complex enough to merit inclusion in the manual.

Right now, it's mainly described in the `rx' doc string, which is fairly well-written but quite long and a bit unstructured. Describing it in the manual permits a different pace and style of exposition, the inclusion of examples and related information, structured into separate sections with cross-references.

Proposed patch attached. It covers all rx features, functions, macros, including the pcase pattern, and a mention of the corresponding string regexp constructs.

The existing `rx' doc string can be left unchanged, or reduced to something more concise, perhaps without a description of the entire rx language but with a manual reference. Suggestions are welcome.

[0001-Describe-the-rx-notation-in-the-elisp-manual.patch (application/octet-stream, attachment)]

Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#36496; Package emacs. (Thu, 04 Jul 2019 15:02:01 GMT) Full text and rfc822 format available.

Message #8 received at 36496 <at> debbugs.gnu.org (full text, mbox):

From: Drew Adams <drew.adams <at> oracle.com>
To: Mattias Engdegård <mattiase <at> acm.org>,
 36496 <at> debbugs.gnu.org
Subject: RE: bug#36496: [PATCH] Describe the rx notation in the lisp manual
Date: Thu, 4 Jul 2019 07:59:31 -0700 (PDT)
> The rx notation is useful and complex enough to merit inclusion in the
> manual.
>
> Right now, it's mainly described in the `rx' doc string, which is fairly
> well-written but quite long and a bit unstructured. Describing it in the
> manual permits a different pace and style of exposition, the inclusion of
> examples and related information, structured into separate sections with
> cross-references.

Indeed.  Bonne initiative !
Thanks for working on this.

Like `cl-loop' and Unix or GNU/Linux `find',
`rx' is practically a language unto itself.
But fortunately (unlike `cl-loop') it is
quite Lispy.




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#36496; Package emacs. (Thu, 04 Jul 2019 16:29:01 GMT) Full text and rfc822 format available.

Message #11 received at 36496 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Mattias Engdegård <mattiase <at> acm.org>
Cc: 36496 <at> debbugs.gnu.org
Subject: Re: bug#36496: [PATCH] Describe the rx notation in the lisp manual
Date: Thu, 04 Jul 2019 19:28:01 +0300
> From: Mattias Engdegård <mattiase <at> acm.org>
> Date: Thu, 4 Jul 2019 14:13:26 +0200
> 
> The rx notation is useful and complex enough to merit inclusion in the manual.
> 
> Right now, it's mainly described in the `rx' doc string, which is fairly well-written but quite long and a bit unstructured. Describing it in the manual permits a different pace and style of exposition, the inclusion of examples and related information, structured into separate sections with cross-references.
> 
> Proposed patch attached. It covers all rx features, functions, macros, including the pcase pattern, and a mention of the corresponding string regexp constructs.

This is a large section.  The ELisp reference is already a large book,
printed in two separate volumes.  So I think if we want to include
this section, it will have to be on a separate file that is
conditionally included @ifnottex.

Alternatively, we could make this a separate manual.

> The existing `rx' doc string can be left unchanged, or reduced to something more concise, perhaps without a description of the entire rx language but with a manual reference. Suggestions are welcome.

Yes, the doc string should be reduced to the summary of the
constructs.

> +@table @code
> +@item (let @var{ref} @var{rx-expr}@dots{})
> +Bind the name @var{ref} to a submatch that matches @var{rx-expr}@enddots{}.
   ^^^^^^^^^^^^^^^^^^^^^^^
"Bind the symbol @var{ref}", no?

> +@example
> +@group
> +(rx "/*"                          ; Initial /*
> +    (zero-or-more
> +     (or (not (any "*"))          ;  Either non-*,
> +         (seq "*"                 ;  or * followed by
> +              (not (any "/")))))  ;  non-/
> +    (one-or-more "*")             ; At least one star,
> +    "/")                          ; and the final /
> +@end group
> +@end example
> +
> +or, using shorter synonyms and written more compactly,

This last line needs @noindent before it.

> +@table @asis
> +@item @code{"some-string"}

Why @code{"..."} and not @samp{...}?  The latter will look better both
in print and in Info format.

> +Corresponding string regexp: @samp{AB <at> dots{}} (subexpressions in sequence).
                                ^^^^^^^^^^^^^^^^
I think this should use @samp{@var{a}@var{b}@dots{}} instead.  And
likewise for the other "corresponding string regexps".  The reason is
that neither A nor B stand for themselves, literally, they are
meta-variables.

> +Match the @var{rx}s once or not at all.@*

"Match @var{rx} or an empty string" sounds better to me.

> +Match the @var{rx}s zero or more times, non-greedily.@*

I would add here a cross-reference to where greedy matching is
described.

> +@item @code{(any @var{charset}@dots{})}

Please don't call this "charset", as that term is already taken by a
very different creature in Emacs.  I suggest "character set" instead.

> +Each @var{charset} is a character, a string representing the set of
> +its characters, a range or a character class.  A range is either a
> +hyphen-separated string like @code{"A-Z"}, or a cons of characters
> +like @code{(?A . ?Z)}.

Again, a cross-reference to where "character class" described would be
good here, as would a @cindex entry for "character class in rx".

> +@item @code{space}, @code{whitespace}, @code{white}
> +Match any character that has whitespace syntax.

Only ASCII or also non-ASCII?  This should be spelled out.

> +@xref{Syntax Class Table} for details.  Please note that
                            ^
Comma missing there.

> +@kbd{M-x describe-categories @key{RET}}.  @xref{Categories} for how
                                                              ^
Likewise.

Thanks.




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#36496; Package emacs. (Fri, 05 Jul 2019 14:15:02 GMT) Full text and rfc822 format available.

Message #14 received at 36496 <at> debbugs.gnu.org (full text, mbox):

From: Mattias Engdegård <mattiase <at> acm.org>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 36496 <at> debbugs.gnu.org
Subject: Re: bug#36496: [PATCH] Describe the rx notation in the lisp manual
Date: Fri, 5 Jul 2019 16:13:52 +0200
[Message part 1 (text/plain, inline)]
4 juli 2019 kl. 18.28 skrev Eli Zaretskii <eliz <at> gnu.org>:
> 
> This is a large section.  The ELisp reference is already a large book,
> printed in two separate volumes.  So I think if we want to include
> this section, it will have to be on a separate file that is
> conditionally included @ifnottex.
> 
> Alternatively, we could make this a separate manual.

It is about 7-8 pages in all. One page could be saved by combining the character class descriptions with the existing ones; they are basically the same. However, that would probably preclude separation into separate files or manuals.

The category names also take up about one page, but that information isn't available anywhere else, since those names are specific to rx. (It would be nice if the names were defined along with the categories, but that isn't the case at present.)

I would prefer @ifnottex to having a separate manual, since one of the points is to make rx feel like a part of elisp and a genuine, practical alternative to regexp strings rather than an add-on. For example, the "Complex Regexp Example" turned out to be a good place for an rx version.

The revised patch (attached) does not separate the contents, because I wanted to hear your opinion on the matter first.

>> The existing `rx' doc string can be left unchanged, or reduced to something more concise, perhaps without a description of the entire rx language but with a manual reference. Suggestions are welcome.
> 
> Yes, the doc string should be reduced to the summary of the
> constructs.

Good, let's do that when the changes to the manual are done.

>> +Bind the name @var{ref} to a submatch that matches @var{rx-expr}@enddots{}.
>   ^^^^^^^^^^^^^^^^^^^^^^^
> "Bind the symbol @var{ref}", no?

Yes, thank you.

>> +or, using shorter synonyms and written more compactly,
> 
> This last line needs @noindent before it.

Added, and in another place.

>> +@table @asis
>> +@item @code{"some-string"}
> 
> Why @code{"..."} and not @samp{...}?  The latter will look better both
> in print and in Info format.

I looked at the result in all formats (pdf, info, html) and came to the opposite conclusion; it makes it clear that it's about a string literal. It's not a strongly held opinion, however.

>> +Corresponding string regexp: @samp{AB <at> dots{}} (subexpressions in sequence).
>                                ^^^^^^^^^^^^^^^^
> I think this should use @samp{@var{a}@var{b}@dots{}} instead. And
> likewise for the other "corresponding string regexps".  The reason is
> that neither A nor B stand for themselves, literally, they are
> meta-variables.

Right; again I made experiments, and ended up with @samp{var{A}@var{B}@dots{}}. The upper-case variables looked much better in print and html.

>> +Match the @var{rx}s once or not at all.@*
> 
> "Match @var{rx} or an empty string" sounds better to me.

Much better, thank you. Changed in all places.

>> +Match the @var{rx}s zero or more times, non-greedily.@*
> 
> I would add here a cross-reference to where greedy matching is
> described.

Done, with a separate sub subheading for the non-greedy stuff.

>> +@item @code{(any @var{charset}@dots{})}
> 
> Please don't call this "charset", as that term is already taken by a
> very different creature in Emacs.  I suggest "character set" instead.

Yes, I ended up using "set" since it's shorter and even better in this case.

>> +Each @var{charset} is a character, a string representing the set of
>> +its characters, a range or a character class.  A range is either a
>> +hyphen-separated string like @code{"A-Z"}, or a cons of characters
>> +like @code{(?A . ?Z)}.
> 
> Again, a cross-reference to where "character class" described would be
> good here, as would a @cindex entry for "character class in rx".

Done; the cross-reference is just a "see below" since it's very near.

>> +@item @code{space}, @code{whitespace}, @code{white}
>> +Match any character that has whitespace syntax.
> 
> Only ASCII or also non-ASCII?  This should be spelled out.

It's a matter of the syntax table; I used the exact formulation of the existing char class description.

>> +@xref{Syntax Class Table} for details.  Please note that
>                            ^
> Comma missing there.

Ah, yes. Apparently, a comma is inserted automatically in the TeX version, so that we get the desired "See Section XIV, page 123, for details"; this is documented. In the info and html versions there is no page number, so a comma doesn't feel like proper English: "See Section XIV, for details" has a distinct German tone to my ears.
Explicit comma after @xref seems to be common in the Emacs manuals, so rather than to fight it out I castled the clauses.

[0001-Describe-the-rx-notation-in-the-elisp-manual-bug-364.patch (application/octet-stream, attachment)]

Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#36496; Package emacs. (Sat, 06 Jul 2019 00:11:01 GMT) Full text and rfc822 format available.

Message #17 received at 36496 <at> debbugs.gnu.org (full text, mbox):

From: Richard Stallman <rms <at> gnu.org>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: mattiase <at> acm.org, 36496 <at> debbugs.gnu.org
Subject: Re: bug#36496: [PATCH] Describe the rx notation in the lisp manual
Date: Fri, 05 Jul 2019 20:10:26 -0400
[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

The ideal goal of rx is to make that the way most people write regexps
for Emacs.  That would be an improvement because rx syntax is more
understandable.  If this happens, we will need to have rx syntax in the
Emacs Lisp Manual.

In the past, various practical factors have made rx somewhat inconvenient,
and that prevented rx from competing with the regexp syntax.
Recently we have made some improvements in rx; are they enough to
make rx a real competitor for regexps?


-- 
Dr Richard Stallman
President, Free Software Foundation (https://gnu.org, https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)






Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#36496; Package emacs. (Sat, 06 Jul 2019 06:48:01 GMT) Full text and rfc822 format available.

Message #20 received at 36496 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: rms <at> gnu.org
Cc: mattiase <at> acm.org, 36496 <at> debbugs.gnu.org
Subject: Re: bug#36496: [PATCH] Describe the rx notation in the lisp manual
Date: Sat, 06 Jul 2019 09:47:30 +0300
> From: Richard Stallman <rms <at> gnu.org>
> Cc: mattiase <at> acm.org, 36496 <at> debbugs.gnu.org
> Date: Fri, 05 Jul 2019 20:10:26 -0400
> 
> In the past, various practical factors have made rx somewhat inconvenient,
> and that prevented rx from competing with the regexp syntax.
> Recently we have made some improvements in rx; are they enough to
> make rx a real competitor for regexps?

I cannot answer the question without knowing which practical factors
made rx inconvenient in the past.  Where can one find this
information?




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#36496; Package emacs. (Sat, 06 Jul 2019 09:09:02 GMT) Full text and rfc822 format available.

Message #23 received at 36496 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Mattias Engdegård <mattiase <at> acm.org>
Cc: 36496 <at> debbugs.gnu.org
Subject: Re: bug#36496: [PATCH] Describe the rx notation in the lisp manual
Date: Sat, 06 Jul 2019 12:08:08 +0300
> From: Mattias Engdegård <mattiase <at> acm.org>
> Date: Fri, 5 Jul 2019 16:13:52 +0200
> Cc: 36496 <at> debbugs.gnu.org
> 
> > This is a large section.  The ELisp reference is already a large book,
> > printed in two separate volumes.  So I think if we want to include
> > this section, it will have to be on a separate file that is
> > conditionally included @ifnottex.
> > 
> > Alternatively, we could make this a separate manual.
> 
> It is about 7-8 pages in all.

It's more that 2500 lines.  We have in doc/misc/ separate manuals much
smaller than this.  So making a separate manual out of this is not
radically different from what we have already.

> One page could be saved by combining the character class descriptions with the existing ones; they are basically the same. However, that would probably preclude separation into separate files or manuals.
> 
> The category names also take up about one page, but that information isn't available anywhere else, since those names are specific to rx. (It would be nice if the names were defined along with the categories, but that isn't the case at present.)

I don't think we should go out of our way to make this text shorter.
it is well written, and doesn't waste words, so any attempt to make it
shorter will IMO make it less useful.

> I would prefer @ifnottex to having a separate manual

Either alternative is fine with me.

> The revised patch (attached) does not separate the contents, because I wanted to hear your opinion on the matter first.

Opinion on which matter? on whether or not make it a separate manual?
If so, you now have my opinion.

> >> +@xref{Syntax Class Table} for details.  Please note that
> >                            ^
> > Comma missing there.
> 
> Ah, yes. Apparently, a comma is inserted automatically in the TeX version, so that we get the desired "See Section XIV, page 123, for details"; this is documented. In the info and html versions there is no page number, so a comma doesn't feel like proper English: "See Section XIV, for details" has a distinct German tone to my ears.
> Explicit comma after @xref seems to be common in the Emacs manuals, so rather than to fight it out I castled the clauses.

The comma is common because older versions of makeinfo insisted on
having it, and would complain if there weren't one.  The latest
versions no longer complain, but we would still like to support the
old versions, as they are ~15 times faster, so some people still keep
them around.

Thanks.




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#36496; Package emacs. (Sat, 06 Jul 2019 11:34:01 GMT) Full text and rfc822 format available.

Message #26 received at 36496 <at> debbugs.gnu.org (full text, mbox):

From: Mattias Engdegård <mattiase <at> acm.org>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 36496 <at> debbugs.gnu.org
Subject: Re: bug#36496: [PATCH] Describe the rx notation in the lisp manual
Date: Sat, 6 Jul 2019 13:33:35 +0200
[Message part 1 (text/plain, inline)]
6 juli 2019 kl. 11.08 skrev Eli Zaretskii <eliz <at> gnu.org>:
> 
>> It is about 7-8 pages in all.
> 
> It's more that 2500 lines.  We have in doc/misc/ separate manuals much
> smaller than this.  So making a separate manual out of this is not
> radically different from what we have already.

It was a visual count of printed pages in the pdf; a lot of lines in the source are mark-up.
In any case, the attached patch has @ifnottex added to it. I didn't move the text to a separate file, since there was no existing "lispref-extras" document to put them in. In addition, some of the additions were to existing sections (pcase, and the complex regexp example).

> Opinion on which matter? on whether or not make it a separate manual?
> If so, you now have my opinion.

Thanks, that's what I meant.

> The comma is common because older versions of makeinfo insisted on
> having it, and would complain if there weren't one.  The latest
> versions no longer complain, but we would still like to support the
> old versions, as they are ~15 times faster, so some people still keep
> them around.

Thank you very much for clearing that up; I always wondered.

Also attached is a patch for replacing the rx doc string with a condensed summary.  I basically copied the one I wrote for ry.

[0001-Describe-the-rx-notation-in-the-elisp-manual-bug-364.patch (application/octet-stream, attachment)]
[0001-Shorter-rx-doc-string-bug-36496.patch (application/octet-stream, attachment)]

Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#36496; Package emacs. (Sat, 06 Jul 2019 11:42:01 GMT) Full text and rfc822 format available.

Message #29 received at 36496 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Mattias Engdegård <mattiase <at> acm.org>
Cc: 36496 <at> debbugs.gnu.org
Subject: Re: bug#36496: [PATCH] Describe the rx notation in the lisp manual
Date: Sat, 06 Jul 2019 14:41:28 +0300
> From: Mattias Engdegård <mattiase <at> acm.org>
> Date: Sat, 6 Jul 2019 13:33:35 +0200
> Cc: 36496 <at> debbugs.gnu.org
> 
> diff --git a/doc/lispref/searching.texi b/doc/lispref/searching.texi
> index ef1cffc446..17c4790f5e 100644
> --- a/doc/lispref/searching.texi
> +++ b/doc/lispref/searching.texi
> @@ -254,6 +254,9 @@ Regular Expressions
>  @menu
>  * Syntax of Regexps::       Rules for writing regular expressions.
>  * Regexp Example::          Illustrates regular expression syntax.
> +@ifnottex
> +* Rx Notation::             An alternative, structured regexp notation.
> +@end ifnottex
>  * Regexp Functions::        Functions for operating on regular expressions.
>  @end menu

I believe you need the same conditional addition in elisp.texi, in the
detailed menu there.

> * lisp/emacs-lisp/rx.el (rx): Replace long description with a condensed
> summary of the rx syntax, with reference to the manual section.

This is OK, but it is inconsistent wrt whether each construct's
description ends in a period.  I suggest to end them all with a
period.

Thanks.




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#36496; Package emacs. (Sat, 06 Jul 2019 12:00:03 GMT) Full text and rfc822 format available.

Message #32 received at 36496 <at> debbugs.gnu.org (full text, mbox):

From: Noam Postavsky <npostavs <at> gmail.com>
To: Mattias Engdegård <mattiase <at> acm.org>
Cc: Eli Zaretskii <eliz <at> gnu.org>, 36496 <at> debbugs.gnu.org
Subject: Re: bug#36496: [PATCH] Describe the rx notation in the lisp manual
Date: Sat, 06 Jul 2019 07:59:03 -0400
Mattias Engdegård <mattiase <at> acm.org> writes:

> +(zero-or-more RX...) Match RXs zero or more times.  Alias: *, 0+
> +(one-or-more RX...)  Match RXs one or more times.  Alias: +, 1+
> +(zero-or-one RX...)  Match RXs or the empty string.  Alias: ?, opt, optional

*, +, and ? are not exact aliases of the above: they're always greedy
(as opposed to depending on rx-greedy-flag).  I think it's a bit
confusing to rely on the description of minimal-match and maximal-match
to explain that.

> +(minimal-match RX)  Match RX, with zero-or-more, one-or-more,
> +                zero-or-one, 0+, 1+, opt, and optional
> +                using non-greedy matching.
> +(maximal-match RX)  Match RX, with zero-or-more, one-or-more,
> +                zero-or-one, 0+, 1+, opt, and optional
> +                using greedy matching, which is the default.




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#36496; Package emacs. (Sat, 06 Jul 2019 18:58:02 GMT) Full text and rfc822 format available.

Message #35 received at 36496 <at> debbugs.gnu.org (full text, mbox):

From: Mattias Engdegård <mattiase <at> acm.org>
To: Eli Zaretskii <eliz <at> gnu.org>, Noam Postavsky <npostavs <at> gmail.com>
Cc: 36496 <at> debbugs.gnu.org
Subject: Re: bug#36496: [PATCH] Describe the rx notation in the lisp manual
Date: Sat, 6 Jul 2019 20:56:57 +0200
[Message part 1 (text/plain, inline)]
6 juli 2019 kl. 13.41 skrev Eli Zaretskii <eliz <at> gnu.org>:
> 
> I believe you need the same conditional addition in elisp.texi, in the
> detailed menu there.

Thank you, forgot that one. Added.

>> * lisp/emacs-lisp/rx.el (rx): Replace long description with a condensed
>> summary of the rx syntax, with reference to the manual section.
> 
> This is OK, but it is inconsistent wrt whether each construct's
> description ends in a period.  I suggest to end them all with a
> period.

Added, except at the end of the lists of aliases which looked better with a minimum of punctuation (and weren't sentences to begin with).

6 juli 2019 kl. 13.59 skrev Noam Postavsky <npostavs <at> gmail.com>:
> 
> *, +, and ? are not exact aliases of the above: they're always greedy
> (as opposed to depending on rx-greedy-flag).  I think it's a bit
> confusing to rely on the description of minimal-match and maximal-match
> to explain that.

Ah, you called out my little white lie. They are synonyms in practice, because almost nobody uses minimal-match, probably for good reasons. (xr used to generate {minimal|maximal}-match, but it was decidedly less readable so it got changed.)

Yet you are right in the sense that the documentation should not lie or wilfully obscure the workings. There appears to be no good solution, because the underlying design isn't very good. It might be different if minimal-match affected the entire expression inside, including (or ...) and (** ...), but that will have to wait for the next big engine.

The new patch versions describe the semantics more objectively, while still recommending the user to stay clear of minimal-match. Good enough?

[0001-Describe-the-rx-notation-in-the-elisp-manual-bug-364.patch (application/octet-stream, attachment)]
[0002-Shorter-rx-doc-string-bug-36496.patch (application/octet-stream, attachment)]

Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#36496; Package emacs. (Sat, 06 Jul 2019 19:11:01 GMT) Full text and rfc822 format available.

Message #38 received at 36496 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Mattias Engdegård <mattiase <at> acm.org>
Cc: npostavs <at> gmail.com, 36496 <at> debbugs.gnu.org
Subject: Re: bug#36496: [PATCH] Describe the rx notation in the lisp manual
Date: Sat, 06 Jul 2019 22:10:38 +0300
> From: Mattias Engdegård <mattiase <at> acm.org>
> Date: Sat, 6 Jul 2019 20:56:57 +0200
> Cc: 36496 <at> debbugs.gnu.org
> 
> >> * lisp/emacs-lisp/rx.el (rx): Replace long description with a condensed
> >> summary of the rx syntax, with reference to the manual section.
> > 
> > This is OK, but it is inconsistent wrt whether each construct's
> > description ends in a period.  I suggest to end them all with a
> > period.
> 
> Added, except at the end of the lists of aliases which looked better with a minimum of punctuation (and weren't sentences to begin with).

It still looks jarring:

  +(seq RX...)    Match the RXs in sequence.  Alias: :, sequence, and
  +(or RX...)     Match one of the RXs.  Alias: |
  +
  +(zero-or-more RX...) Match RXs zero or more times.  Alias: 0+
  +(one-or-more RX...)  Match RXs one or more times.  Alias: 1+
  +(zero-or-one RX...)  Match RXs or the empty string.  Alias: opt, optional

Honestly, they look like incorrect English: a sentence, starting with
a capital letter, but not ending with a period.  I hope you will
reconsider.




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#36496; Package emacs. (Sat, 06 Jul 2019 19:13:02 GMT) Full text and rfc822 format available.

Message #41 received at 36496 <at> debbugs.gnu.org (full text, mbox):

From: Noam Postavsky <npostavs <at> gmail.com>
To: Mattias Engdegård <mattiase <at> acm.org>
Cc: Eli Zaretskii <eliz <at> gnu.org>, 36496 <at> debbugs.gnu.org
Subject: Re: bug#36496: [PATCH] Describe the rx notation in the lisp manual
Date: Sat, 06 Jul 2019 15:12:36 -0400
Mattias Engdegård <mattiase <at> acm.org> writes:

> Ah, you called out my little white lie. They are synonyms in practice,
> because almost nobody uses minimal-match, probably for good
> reasons. (xr used to generate {minimal|maximal}-match, but it was
> decidedly less readable so it got changed.)
>
> Yet you are right in the sense that the documentation should not lie
> or wilfully obscure the workings. There appears to be no good
> solution, because the underlying design isn't very good. It might be
> different if minimal-match affected the entire expression inside,
> including (or ...) and (** ...), but that will have to wait for the
> next big engine.
>
> The new patch versions describe the semantics more objectively, while
> still recommending the user to stay clear of minimal-match. Good
> enough?

> +(zero-or-more RX...) Match RXs zero or more times.  Alias: 0+
> +(one-or-more RX...)  Match RXs one or more times.  Alias: 1+
> +(zero-or-one RX...)  Match RXs or the empty string.  Alias: opt, optional
> +(* RX...)       Match RXs zero or more times; greedy.
> +(+ RX...)       Match RXs one or more times; greedy.
> +(? RX...)       Match RXs or the empty string; greedy.

Yep, that looks fine.





Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#36496; Package emacs. (Sat, 06 Jul 2019 19:47:01 GMT) Full text and rfc822 format available.

Message #44 received at 36496 <at> debbugs.gnu.org (full text, mbox):

From: Mattias Engdegård <mattiase <at> acm.org>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: Noam Postavsky <npostavs <at> gmail.com>, 36496 <at> debbugs.gnu.org
Subject: Re: bug#36496: [PATCH] Describe the rx notation in the lisp manual
Date: Sat, 6 Jul 2019 21:45:58 +0200
[Message part 1 (text/plain, inline)]
6 juli 2019 kl. 21.10 skrev Eli Zaretskii <eliz <at> gnu.org>:
> 
> Honestly, they look like incorrect English: a sentence, starting with
> a capital letter, but not ending with a period.  I hope you will
> reconsider.

Very well, full stops added.

[0002-Shorter-rx-doc-string-bug-36496.patch (application/octet-stream, attachment)]

Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#36496; Package emacs. (Sat, 06 Jul 2019 23:57:02 GMT) Full text and rfc822 format available.

Message #47 received at 36496 <at> debbugs.gnu.org (full text, mbox):

From: Richard Stallman <rms <at> gnu.org>
To: Mattias Engdegård <mattiase <at> acm.org>
Cc: eliz <at> gnu.org, 36496 <at> debbugs.gnu.org
Subject: Re: bug#36496: [PATCH] Describe the rx notation in the lisp manual
Date: Sat, 06 Jul 2019 19:56:30 -0400
[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

  > >> It is about 7-8 pages in all.

Would it be feasible to format it differently so that it comes out as
fewer pages?  That might be possible by using Texinfo a different way.
Or perhaps not.  That is why I am asking.

Here's another idea: document the two syntaxes in a single table,
where each item says how to do the job in a regexp
and how to do it in rx.

-- 
Dr Richard Stallman
President, Free Software Foundation (https://gnu.org, https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)






Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#36496; Package emacs. (Sun, 07 Jul 2019 00:00:02 GMT) Full text and rfc822 format available.

Message #50 received at 36496 <at> debbugs.gnu.org (full text, mbox):

From: Richard Stallman <rms <at> gnu.org>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: mattiase <at> acm.org, 36496 <at> debbugs.gnu.org
Subject: Re: bug#36496: [PATCH] Describe the rx notation in the lisp manual
Date: Sat, 06 Jul 2019 19:59:47 -0400
[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

  > > In the past, various practical factors have made rx somewhat inconvenient,
  > > and that prevented rx from competing with the regexp syntax.
  > > Recently we have made some improvements in rx; are they enough to
  > > make rx a real competitor for regexps?

  > I cannot answer the question without knowing which practical factors
  > made rx inconvenient in the past.  Where can one find this
  > information?

I don't know.  I think people discussed it in the
past -- perhaps on emacs-devel.  I don't remember details.

What's clear is that rx didn't replace regexp syntax in the past.
There had to be reasons.

-- 
Dr Richard Stallman
President, Free Software Foundation (https://gnu.org, https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)






Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#36496; Package emacs. (Sun, 07 Jul 2019 00:37:02 GMT) Full text and rfc822 format available.

Message #53 received at 36496 <at> debbugs.gnu.org (full text, mbox):

From: Drew Adams <drew.adams <at> oracle.com>
To: rms <at> gnu.org, Eli Zaretskii <eliz <at> gnu.org>
Cc: mattiase <at> acm.org, 36496 <at> debbugs.gnu.org
Subject: RE: bug#36496: [PATCH] Describe the rx notation in the lisp manual
Date: Sun, 7 Jul 2019 00:36:24 +0000 (UTC)
>   > I cannot answer the question without knowing which practical factors
>   > made rx inconvenient in the past.  Where can one find this
>   > information?
> 
> I don't know.  I think people discussed it in the
> past -- perhaps on emacs-devel.  I don't remember details.
> 
> What's clear is that rx didn't replace regexp syntax in the past.
> There had to be reasons.

I don't want to sidetrack this thread.  But one of
the things mentioned in some previous threads about
`rx' was that some people (including me) thought it
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.

A regexp string can be very concise (advantage),
even if obtuse (disadvantage).  Much of the time one
doesn't need to dig into the content of the regexp.
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.

In sum, I'd say that one advantage of a regexp is
its concision.  But when you need or want to grok
it it's good to be able to get its `rx' sexp.

With such a feature people could use `rx' or its
result in code, au choix.  And they could see the
`rx' equivalent for a regexp on demand.

This is orthogonal to having good doc for `rx'.
I mention it only because the question came up of
disadvantages of `rx' (reasons why it might not
replace a regexp).

(Another reason, if it's true, would be if there
are some regexp constructs that `rx' cannot
handle/reproduce.)




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#36496; Package emacs. (Sun, 07 Jul 2019 02:30:03 GMT) Full text and rfc822 format available.

Message #56 received at 36496 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Mattias Engdegård <mattiase <at> acm.org>
Cc: npostavs <at> gmail.com, 36496 <at> debbugs.gnu.org
Subject: Re: bug#36496: [PATCH] Describe the rx notation in the lisp manual
Date: Sun, 07 Jul 2019 05:29:20 +0300
> From: Mattias Engdegård <mattiase <at> acm.org>
> Date: Sat, 6 Jul 2019 21:45:58 +0200
> Cc: Noam Postavsky <npostavs <at> gmail.com>, 36496 <at> debbugs.gnu.org
> 
> > Honestly, they look like incorrect English: a sentence, starting with
> > a capital letter, but not ending with a period.  I hope you will
> > reconsider.
> 
> Very well, full stops added.

Thanks, LGTM.




Merged 31698 36496. Request was from Mattias Engdegård <mattiase <at> acm.org> to control <at> debbugs.gnu.org. (Sun, 07 Jul 2019 10:16:01 GMT) Full text and rfc822 format available.

Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#36496; Package emacs. (Sun, 07 Jul 2019 11:32:02 GMT) Full text and rfc822 format available.

Message #61 received at 36496 <at> debbugs.gnu.org (full text, mbox):

From: Mattias Engdegård <mattiase <at> acm.org>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: Noam Postavsky <npostavs <at> gmail.com>, Richard Stallman <rms <at> gnu.org>,
 36496 <at> debbugs.gnu.org
Subject: Re: bug#36496: [PATCH] Describe the rx notation in the lisp manual
Date: Sun, 7 Jul 2019 13:31:06 +0200
7 juli 2019 kl. 04.29 skrev Eli Zaretskii <eliz <at> gnu.org>:

> Thanks, LGTM.

Thanks for reviewing! Pushed to master.

7 juli 2019 kl. 01.56 skrev Richard Stallman <rms <at> gnu.org>:

> Would it be feasible to format it differently so that it comes out as
> fewer pages?  That might be possible by using Texinfo a different way.

One way, already mentioned, would be to merge the character class descriptions for rx and string regexps. That would save about one page, at the cost of making the list slightly messier since rx has synonyms for each item which are not legal in string regexps ([:digit:] vs `digit', `numeric' and `num').

Eliding the categories table would save another page, if we accept a reference to other formats or the rx doc string.

I see little room beyond that. We could remove the examples, but they are short and doing so would make an already dry section even drier.

> Here's another idea: document the two syntaxes in a single table,
> where each item says how to do the job in a regexp
> and how to do it in rx.


Probably not a bad idea and one that would put the syntaxes on equal footing, but it involves a complete rewrite of all the regexp sections; more than I am prepared to do right now.

Should this bug be kept open for possible improvements to the print manual, or can we regard that as a separate issue?





Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#36496; Package emacs. (Sun, 07 Jul 2019 14:34:02 GMT) Full text and rfc822 format available.

Message #64 received at 36496 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Mattias Engdegård <mattiase <at> acm.org>
Cc: npostavs <at> gmail.com, rms <at> gnu.org, 36496 <at> debbugs.gnu.org
Subject: Re: bug#36496: [PATCH] Describe the rx notation in the lisp manual
Date: Sun, 07 Jul 2019 17:33:23 +0300
> From: Mattias Engdegård <mattiase <at> acm.org>
> Date: Sun, 7 Jul 2019 13:31:06 +0200
> Cc: Noam Postavsky <npostavs <at> gmail.com>, 36496 <at> debbugs.gnu.org,
>         Richard Stallman <rms <at> gnu.org>
> 
> Should this bug be kept open for possible improvements to the print manual, or can we regard that as a separate issue?

It doesn't really matter, IMO.  I'd say leave this bug open, as
opening another doesn't seem to be worth the hassle.

Thanks.




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#36496; Package emacs. (Sun, 07 Jul 2019 23:52:02 GMT) Full text and rfc822 format available.

Message #67 received at 36496 <at> debbugs.gnu.org (full text, mbox):

From: Richard Stallman <rms <at> gnu.org>
To: Drew Adams <drew.adams <at> oracle.com>
Cc: mattiase <at> acm.org, eliz <at> gnu.org, 36496 <at> debbugs.gnu.org
Subject: Re: bug#36496: [PATCH] Describe the rx notation in the lisp manual
Date: Sun, 07 Jul 2019 19:51:24 -0400
[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

  > 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 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.  Compilation could convert a constant non-string, for
such args, to a regexp string.

Commands that read a regexp using the minibuffer could offer a key to
say that you are entering rx format.  The only problem is, which key
would it be?

-- 
Dr Richard Stallman
President, Free Software Foundation (https://gnu.org, https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)






Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#36496; Package emacs. (Mon, 08 Jul 2019 00:57:01 GMT) Full text and rfc822 format available.

Message #70 received at 36496 <at> debbugs.gnu.org (full text, mbox):

From: Drew Adams <drew.adams <at> oracle.com>
To: rms <at> gnu.org
Cc: mattiase <at> acm.org, eliz <at> gnu.org, 36496 <at> debbugs.gnu.org
Subject: RE: 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'?




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#36496; Package emacs. (Mon, 08 Jul 2019 23:45:02 GMT) Full text and rfc822 format available.

Message #73 received at 36496 <at> debbugs.gnu.org (full text, mbox):

From: Richard Stallman <rms <at> gnu.org>
To: drew.adams <at> oracle.com, mattiase <at> acm.org, 36496 <at> debbugs.gnu.org
Cc: rms <at> gnu.org
Subject: Re: bug#36496: [PATCH] Describe the rx notation in the lisp manual
Date: Mon, 08 Jul 2019 19:44:06 -0400
[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

Can a regexp string be used as a part of an rx pattern?
For instance, can you do this?

  (or "foo+" "bar+")

If not, that might be good to add, so people can get the benefits of
both formats.  You could use the simple regexp constructs that are
easy to read, and use rx instead of the uglier complex regexp
constructs.


-- 
Dr Richard Stallman
President, Free Software Foundation (https://gnu.org, https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)






Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#36496; Package emacs. (Mon, 08 Jul 2019 23:47:02 GMT) Full text and rfc822 format available.

Message #76 received at 36496 <at> debbugs.gnu.org (full text, mbox):

From: Richard Stallman <rms <at> gnu.org>
To: Drew Adams <drew.adams <at> oracle.com>
Cc: mattiase <at> acm.org, eliz <at> gnu.org, 36496 <at> debbugs.gnu.org
Subject: Re: bug#36496: [PATCH] Describe the rx notation in the lisp manual
Date: Mon, 08 Jul 2019 19:46:37 -0400
[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

  > 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 ...).

  > [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.

  > 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?

  > > 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?

-- 
Dr Richard Stallman
President, Free Software Foundation (https://gnu.org, https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)






Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#36496; Package emacs. (Tue, 09 Jul 2019 00:20:02 GMT) Full text and rfc822 format available.

Message #79 received at 36496 <at> debbugs.gnu.org (full text, mbox):

From: Drew Adams <drew.adams <at> oracle.com>
To: rms <at> gnu.org
Cc: mattiase <at> acm.org, eliz <at> gnu.org, 36496 <at> debbugs.gnu.org
Subject: RE: bug#36496: [PATCH] Describe the rx notation in the lisp manual
Date: Mon, 8 Jul 2019 17:19:32 -0700 (PDT)
>   > 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.)




Removed tag(s) patch. Request was from Noam Postavsky <npostavs <at> gmail.com> to control <at> debbugs.gnu.org. (Wed, 17 Jul 2019 00:29:02 GMT) Full text and rfc822 format available.

Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#36496; Package emacs. (Mon, 25 Apr 2022 15:13:01 GMT) Full text and rfc822 format available.

Message #84 received at 36496 <at> debbugs.gnu.org (full text, mbox):

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: Mattias Engdegård <mattiase <at> acm.org>
Cc: Eli Zaretskii <eliz <at> gnu.org>, 36496 <at> debbugs.gnu.org,
 Noam Postavsky <npostavs <at> gmail.com>, Richard Stallman <rms <at> gnu.org>
Subject: Re: bug#36496: [PATCH] Describe the rx notation in the lisp manual
Date: Mon, 25 Apr 2022 17:12:35 +0200
Mattias Engdegård <mattiase <at> acm.org> writes:

> Thanks for reviewing! Pushed to master.

The discussion then turned to other matters, but as far as I can tell,
the issue was fixed (i.e., Mattias added rx documentation to the
manual), so I'm closing this bug report.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no




bug closed, send any further explanations to 36496 <at> debbugs.gnu.org and Mattias Engdegård <mattiase <at> acm.org> Request was from Lars Ingebrigtsen <larsi <at> gnus.org> to control <at> debbugs.gnu.org. (Mon, 25 Apr 2022 15:13:02 GMT) Full text and rfc822 format available.

bug archived. Request was from Debbugs Internal Request <help-debbugs <at> gnu.org> to internal_control <at> debbugs.gnu.org. (Tue, 24 May 2022 11:24:10 GMT) Full text and rfc822 format available.

This bug report was last modified 1 year and 309 days ago.

Previous Next


GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.