Re: Clarify `pcase' `rx' pattern doc

[Eli Zaretskii]

> From: Michael Heerdegen <address@hidden>
> Cc: address@hidden
> Date: Thu, 21 Jun 2018 13:13:58 +0200
> 
> Eli Zaretskii <address@hidden> writes:
> 
> > >  (pcase-defmacro rx (&rest regexps)
> > > -  "Build a `pcase' pattern matching `rx' regexps.
> > > -The REGEXPS are interpreted as by `rx'.  The pattern matches if
> > > -the regular expression so constructed matches EXPVAL, as if
> > > -by `string-match'.
> > > +  "Build a `pcase' pattern matching with `rx' REGEXPS.
> >
> > I don't like calling this "regexp".  Elsewhere in rx documentation we
> > say either "regexps in sexp form" or just "form".  Using "regexp"
> > might confuse the reader to think these are the "normal" regexp
> > strings.
> 
> But hey, ehm - I didn't change this, I just upcased the argument name.

That's true, but your goal was to improve the existing doc string,
right?  I'm saying that using "REGEXP" doesn't improve it.

> > > -  (let VAR FORM...)  creates a new explicitly numbered submatch
> > > -                     that matches FORM and binds the match to
> > > -                     VAR.
> > > -  (backref VAR)      creates a backreference to the submatch
> > > -                     introduced by a previous (let VAR ...)
> > > -                     construct.
> > > +  (let VAR REGEXPS...)  creates a new explicitly numbered
> > > +                        submatch that matches the `rx' REGEXPS
> > > +                        and binds the match to VAR.
> >
> > IMO, this change is for the worse: the original clearly indicated that
> > FORM is the rx-style regexp, whereas the new text blurs this
> > indication.
> 
> And here I just used the same name for the `let' argument, since it's of
> exactly the same type as the argument of the `rx' pattern.
> 
> Even the normal `rx' macro (not the pcase macro) names its &rest
> argument "REGEXPS" - so I think now what I suggested was just
> consistent.  Of cause could we change all occurrences of "REGEXPS" to
> "FORMS" or something better, but I think this is not in the scope of my
> suggested commit.

Could you please elaborate on what you didn't like or found confusing
in the original text, and why?  Then perhaps I could suggest how to
modify the text to satisfy us both.  OK?