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

[Stephen Berman via "Bug reports for GNU Emacs, the Swiss army knife of text editors" <bug-gnu-emacs@gnu.org>]

On Sat, 08 Jun 2024 17:58:17 +0300 Eli Zaretskii <eliz@gnu.org> wrote:

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

Since this effect of using a backslash is part of what
substitute-command-keys does (and it's commented there: ";; 1C. \`f' is
replaced with a fontified f."), would adding a comment to y-or-n-p be an
exception or would all callers of substitute-command-keys that use this
handling of the backslash also need to have such a comment?

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

The value can break key-valid-p, e.g. by only optionally matching
whitespace.  Maybe that's reason enough to have key-valid-p bind it to
nil.  The OP's use case (mentioned the the stackexchange thread Drew
referred to) seems legitimate, but maybe it can be achieved without
changing search-spaces-regexp.

Steve Berman