GNU bug report logs - #51101
29.0.50; read-char-from-minibuffer accepts Enter even when not a choice.

Previous Next

Full log

View this message in rfc822 format

From: Juri Linkov <juri <at> linkov.net>
To: Lars Ingebrigtsen <larsi <at> gnus.org>
Cc: "David M. Koppelman" <koppel <at> ece.lsu.edu>, 51101 <at> debbugs.gnu.org
Subject: bug#51101: 29.0.50; read-char-from-minibuffer accepts Enter even when not a choice.
Date: Sun, 10 Oct 2021 20:31:31 +0300

close 51101 28.0.60
quit

>> Execute:
>>
>>  (read-char-from-minibuffer "Answer y or n" '(?y ?n))
>>
>> and press Enter. The form returns Enter (13) rather than re-prompting
>> for a y or n.
>
> It seems undocumented what RET is supposed to do in this function --
> I've added Juri to the CCs, perhaps he has some comments.

RET is supposed to do exactly the same what it did in
read-char-choice-with-read-key, or when these variables are non-nil:
read-char-choice-use-read-key and y-or-n-p-use-read-key,
i.e. to ignore RET and read the character again.

So this is fixed accordingly now in 28.0.

>> This causes a dataloss threat due to read-char-from-minibuffer being
>> called through ask-user-about-supersession-threat.
>>
>> Even if the read-char-from-minibuffer bug is quickly fixed, I'd
>> sleep better if the following patch were applied to userlock.el:
>>
>> @@ -194,7 +194,9 @@ ask-user-about-supersession-threat
>>  		       (list "File reverted" filename)))
>>  	      ((eq answer ?n)
>>  	       (signal 'file-supersession
>> -		       (list "File changed on disk" filename)))))
>> +		       (list "File changed on disk" filename)))
>> +              ((eq answer ?y))
>> +              (t (setq answer nil))))

I installed the patch provided by David as well.

> But I think ask-user-about-supersession-threat is working correctly here
> already (almost by chance).  RET means "yes" in functions like
> `y-or-n-p', which this is basically an extended version of, so it should
> work as "yes" here, too.

Maybe it works here because ask-user-about-supersession-threat
is called from C with some flag that disables signaling 'quit'.
But when trying to type RET after (y-or-n-p "Answer y or n: ")
it terminates with the 'quit' signal.  And indeed in the map
used by y-or-n-p, RET is bound to 'exit':

    (define-key query-replace-map "\r" 'exit)

I noticed the recent commit ec9f25bd356c7c81d94c78f11100b97d6d52ce97
saying that RET means "yes" in y-or-n-p.  But anyway since RET
now does the same that read-char-choice-with-read-key does,
so I removed mentions of RET from the doc string.  Or should
the fixed behavior be mentioned?

Previous Next

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