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

Previous Next

Package: emacs;

Reported by: "David M. Koppelman" <koppel <at> ece.lsu.edu>

Date: Fri, 8 Oct 2021 20:20:01 UTC

Severity: normal

Found in version 29.0.50

Fixed in version 28.0.60

Done: Juri Linkov <juri <at> linkov.net>

Bug is archived. No further changes may be made.

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 51101 in the body.
You can then email your comments to 51101 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

View this report as an mbox folder, status mbox, maintainer mbox


Report forwarded to bug-gnu-emacs <at> gnu.org:
bug#51101; Package emacs. (Fri, 08 Oct 2021 20:20:01 GMT) Full text and rfc822 format available.

Acknowledgement sent to "David M. Koppelman" <koppel <at> ece.lsu.edu>:
New bug report received and forwarded. Copy sent to bug-gnu-emacs <at> gnu.org. (Fri, 08 Oct 2021 20:20:02 GMT) Full text and rfc822 format available.

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

From: "David M. Koppelman" <koppel <at> ece.lsu.edu>
To: bug-gnu-emacs <at> gnu.org
Subject: 29.0.50; read-char-from-minibuffer accepts Enter even when not a
 choice.
Date: Fri, 08 Oct 2021 15:19:48 -0500
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.

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))))
       (message
        "File on disk now will become a backup file if you save these changes.")
       (setq buffer-backed-up nil))))


In GNU Emacs 29.0.50 (build 1, x86_64-pc-linux-gnu, GTK+ Version 3.24.30, cairo version 1.17.4)
 of 2021-10-08 built on dmk-laptop-21
Repository revision: e73c9ac4ed4ce0a4b423dae6acbfb384c1afbce0
Repository branch: master
Windowing system distributor 'The X.Org Foundation', version 11.0.12101002
System Description: Fedora Linux 35 (KDE Plasma Prerelease)

Configured using:
 'configure 'CFLAGS=-O3 -march=native' --without-pop
 --with-native-compilation'

Configured features:
ACL CAIRO DBUS FREETYPE GIF GLIB GMP GNUTLS GPM GSETTINGS HARFBUZZ JPEG
JSON LCMS2 LIBOTF LIBSELINUX LIBSYSTEMD LIBXML2 M17N_FLT MODULES
NATIVE_COMP NOTIFY INOTIFY PDUMPER PNG RSVG SECCOMP SOUND THREADS TIFF
TOOLKIT_SCROLL_BARS X11 XDBE XIM XPM GTK3 ZLIB

Important settings:
  value of $LC_COLLATE: C
  value of $LC_TIME: C
  value of $LANG: en_US.UTF-8
  locale-coding-system: utf-8-unix

Major mode: Lisp Interaction

Minor modes in effect:
  tooltip-mode: t
  global-eldoc-mode: t
  eldoc-mode: t
  show-paren-mode: t
  electric-indent-mode: t
  mouse-wheel-mode: t
  tool-bar-mode: t
  menu-bar-mode: t
  file-name-shadow-mode: t
  global-font-lock-mode: t
  font-lock-mode: t
  blink-cursor-mode: t
  auto-composition-mode: t
  auto-encryption-mode: t
  auto-compression-mode: t
  line-number-mode: t
  indent-tabs-mode: t
  transient-mark-mode: t

Load-path shadows:
None found.

Features:
(shadow sort mail-extr emacsbug message rmc puny dired dired-loaddefs
rfc822 mml mml-sec epa derived epg rfc6068 epg-config gnus-util rmail
rmail-loaddefs auth-source cl-seq eieio eieio-core cl-macs
eieio-loaddefs password-cache json map text-property-search seq gv
byte-opt bytecomp byte-compile cconv mm-decode mm-bodies mm-encode
mail-parse rfc2231 mailabbrev gmm-utils mailheader sendmail rfc2047
rfc2045 ietf-drums mm-util mail-prsvr mail-utils time-date subr-x
cl-loaddefs cl-lib iso-transl tooltip eldoc paren electric uniquify
ediff-hook vc-hooks lisp-float-type elisp-mode mwheel term/x-win x-win
term/common-win x-dnd tool-bar dnd fontset image regexp-opt fringe
tabulated-list replace newcomment text-mode lisp-mode prog-mode register
page tab-bar menu-bar rfn-eshadow isearch easymenu timer select
scroll-bar mouse jit-lock font-lock syntax font-core term/tty-colors
frame minibuffer cl-generic cham georgian utf-8-lang misc-lang
vietnamese tibetan thai tai-viet lao korean japanese eucjp-ms cp51932
hebrew greek romanian slovak czech european ethiopic indian cyrillic
chinese composite emoji-zwj charscript charprop case-table epa-hook
jka-cmpr-hook help simple abbrev obarray cl-preloaded nadvice button
loaddefs faces cus-face macroexp files window text-properties overlay
sha1 md5 base64 format env code-pages mule custom widget
hashtable-print-readable backquote threads dbusbind inotify lcms2
dynamic-setting system-font-setting font-render-setting cairo
move-toolbar gtk x-toolkit x multi-tty make-network-process
native-compile emacs)

Memory information:
((conses 16 68625 10824)
 (symbols 48 6630 0)
 (strings 32 19929 1554)
 (string-bytes 1 675055)
 (vectors 16 13948)
 (vector-slots 8 286810 18217)
 (floats 8 24 38)
 (intervals 56 232 0)
 (buffers 992 11))






Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#51101; Package emacs. (Sat, 09 Oct 2021 13:10:02 GMT) Full text and rfc822 format available.

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

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: "David M. Koppelman" <koppel <at> ece.lsu.edu>
Cc: 51101 <at> debbugs.gnu.org, Juri Linkov <juri <at> linkov.net>
Subject: Re: bug#51101: 29.0.50; read-char-from-minibuffer accepts Enter
 even when not a choice.
Date: Sat, 09 Oct 2021 15:09:24 +0200
"David M. Koppelman" <koppel <at> 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.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#51101; Package emacs. (Sat, 09 Oct 2021 15:03:02 GMT) Full text and rfc822 format available.

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

From: David Koppelman <koppel <at> ece.lsu.edu>
To: Lars Ingebrigtsen <larsi <at> gnus.org>
Cc: 51101 <at> debbugs.gnu.org, Juri Linkov <juri <at> linkov.net>
Subject: Re: 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
> 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 <at> gnus.org> writes:

> "David M. Koppelman" <koppel <at> 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.




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#51101; Package emacs. (Sun, 10 Oct 2021 17:34:03 GMT) Full text and rfc822 format available.

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

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




bug marked as fixed in version 28.0.60, send any further explanations to 51101 <at> debbugs.gnu.org and "David M. Koppelman" <koppel <at> ece.lsu.edu> Request was from Juri Linkov <juri <at> linkov.net> to control <at> debbugs.gnu.org. (Sun, 10 Oct 2021 17:34:04 GMT) Full text and rfc822 format available.

Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#51101; Package emacs. (Sun, 10 Oct 2021 20:08:02 GMT) Full text and rfc822 format available.

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

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

> 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 must have tested this in the wrong version of Emacs -- I thought I was
testing y-or-n-p in Emacs 26.3 to see what it did there, but I must have
started a more recent version instead.

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

No, that's fine.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no




bug archived. Request was from Debbugs Internal Request <help-debbugs <at> gnu.org> to internal_control <at> debbugs.gnu.org. (Mon, 08 Nov 2021 12:24:04 GMT) Full text and rfc822 format available.

This bug report was last modified 2 years and 141 days ago.

Previous Next


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