GNU bug report logs - #71429
Inconsistent y-or-n-p prompt behavior in Emacs Lisp

Previous Next

Package: emacs;

Reported by: Gabriele Nicolardi <gabriele <at> medialab.sissa.it>

Date: Sat, 8 Jun 2024 07:20:04 UTC

Severity: normal

Done: Stefan Kangas <stefankangas <at> gmail.com>

Bug is archived. No further changes may be made.

Full log


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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Stephen Berman <stephen.berman <at> gmx.net>,
 Stefan Monnier <monnier <at> iro.umontreal.ca>
Cc: gabriele <at> medialab.sissa.it, 71429 <at> debbugs.gnu.org, stefankangas <at> gmail.com
Subject: Re: bug#71429: Inconsistent y-or-n-p prompt behavior in Emacs Lisp
Date: Sat, 08 Jun 2024 17:58:17 +0300
> From: Stephen Berman <stephen.berman <at> gmx.net>
> Cc: Gabriele Nicolardi <gabriele <at> medialab.sissa.it>,  Stefan Kangas
>  <stefankangas <at> gmail.com>,  71429 <at> 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.




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

Previous Next


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