bug#71429: Inconsistent y-or-n-p prompt behavior in Emacs Lisp

[Eli Zaretskii]

> From: Stephen Berman <stephen.berman@gmx.net>
> Cc: Gabriele Nicolardi <gabriele@medialab.sissa.it>,  Stefan Kangas
>  <stefankangas@gmail.com>,  71429@debbugs.gnu.org
> Date: Sat, 08 Jun 2024 15:59:11 +0200
> 
> >> I actually don't understand why we use \\`y' and \\`n' in y-or-n-p.
> >> Why those backslashes, and not just `y' and `n'?  That's your change
> >> in commit a36ecc408a.  If I remove the backslashes, the results are
> >> identical whether or not search-spaces-regexp is let-bound.
> 
> Without the backslashes the cond-clause in substitute-command-keys
> handling sequences starting with "\" is skipped, so "y" and "n" do not
> get the help-key-binding face property.

This should be explained in a comment in y-or-n-p.

> Stepping through substitute-command-keys in Edebug, I see that when the
> regexp ends in '?' or '*' the sexp (key-valid-p k) in
> substitute-command-keys returns nil for k set to "y" and then to "n", so
> these strings do not get the help-key-binding face property and "(\\`y'
> or \\`n') " is returned to y-or-n-p unaltered.  When the regexp does not
> end in '?' or '*', (key-valid-p k) returns t for "y" and "n" and these
> strings get propertized.
> 
> Stepping through key-valid-p, I see that when the regexp ends in '?' or
> '*' the sexp (split-string keys " ") returns (#1="" "y" #1#) for keys
> set to "y", and key-valid-p loops over this lists, and the first element
> "" is an invalid key.  When the regexp does not end in '?' or '*' the
> split-string sexp in key-valid-p returns ("y"), and "y" is valid.

Thanks.  To me, this means that key-valid-p should bind
search-spaces-regexp to nil, because otherwise the value will subvert
its contract.  Do you agree?

I added Stefan Monnier to the discussion in the hope he would have
comments to this.

> And stepping through split-string, I see that when the regexp ends in
> '?' or '*', the invocation of string-match in the while-loop with args
> REGEXP set to " ", STRING set to "y" and START set to 0 returns 0, which
> results in "" being pushed onto the list both before and after "y",
> hence returning (#1="" "y" #1#).  When the regexp does not end in '?' or
> '*', the string-match invocation returns nil and only "y" is pushed onto
> the list.

We should ad to split-string's doc string the fact that
search-spaces-regexp affects its results when SEPARATORS includes
whitespace.