Re: Clarify `pcase' `rx' pattern doc

[Michael Heerdegen]

Eli Zaretskii <address@hidden> writes:

> > > > > + [...]  If the target is not a string, signal an error.
> > > > 
> > > > We want to change that, so I think you can drop that sentence.
> > >
> > > Shouldn't it be dropped when that change is committed?
> > 
> > Then we would break documented behavior then.  What would be the gain?
>
> Sorry, I must be confused about this.  You said "we want to change
> that", so I interpreted that to mean that such a change was not yet
> done and will be done shortly.  IMO, changes in documentation should
> be committed together with code changes that modify the behavior
> described in the documentation, thus my question.  Did I
> misunderstand?

No, I don't think so.

> If you fear that having this sentence in the doc string will somehow
> preclude us from making the code change, or make it harder, then the
> doc string already says that, so if there's a problem, it is already
> with us, no?

No, my fear is that users or package maintainers rely on what we
document now although we surely know what we add to the docs won't hold
later.  IOW, what you suggest to document is a misfeature we want to get
rid of very soon.  I intend to do this right after this commit we speak
about here (but in master).  The main effect would be a merge conflict.

> > AFAIK, in `let' VAR must be a symbol, but it seems the submatch is also
> > numbered as side effect, e.g.
> > 
> > (pcase "Hala"
> >   ((rx "H" (let x "a") (regex ".*") (backref 1)) x))
> > ==> "a"
>
> So you agree that "explicitly named" is a better wording?

I think it would be an improvement, yes.


Michael.