[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#51101: 29.0.50; read-char-from-minibuffer accepts Enter even when no
From: |
David Koppelman |
Subject: |
bug#51101: 29.0.50; read-char-from-minibuffer accepts Enter even when not a choice. |
Date: |
Sat, 09 Oct 2021 10:02:38 -0500 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux) |
> 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.