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

[David Koppelman]

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

That might make sense if someone were expecting a prompt, but this
prompt appears totally unexpectedly when one tries to enter text into
a buffer, often that text includes enter. It would be easy to overlook
the prompt and so suffer dataloss.

David



Lars Ingebrigtsen <larsi@gnus.org> writes:

> "David M. Koppelman" <koppel@ece.lsu.edu> writes:
>
>> 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.
>
>> 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))))
>
> 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.