GNU bug report logs - #32257
26.1; read-multiple-choice inf loops on mouse clicks

Previous Next

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

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

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

From: Noam Postavsky <npostavs <at> gmail.com>
To: bug-gnu-emacs <at> gnu.org
Subject: 26.1; read-multiple-choice inf loops on mouse clicks
Date: Tue, 24 Jul 2018 08:05:45 -0400

X-Debbugs-CC: Andy Moreton <andrewjmoreton <at> gmail.com>, Lars Ingebrigtsen <larsi <at> gnus.org>

Starting from emacs -Q, evaluate:

    (require 'rmc)
    (read-multiple-choice "choice? " '((?a "ay") (?b "bee") (?c "see")))

then click the mouse somewhere instead of answering the prompt, notice
Emacs maxing out CPU, hit C-g.  *Messages* will have a log of the prompt
being repeated many times:

    choice?  (ay, bee, [c] see, ?):  [4435 times]

In GNU Emacs 26.1 (build 1, x86_64-pc-linux-gnu, X toolkit, Xaw scroll bars)
 of 2018-04-09 built on zebian
Repository revision: c267421647510319d2a70554e42f0d1c394dba0a
Windowing system distributor 'The X.Org Foundation', version 11.0.11902000
System Description:	Debian GNU/Linux 9.4 (stretch)

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

From: Noam Postavsky <npostavs <at> gmail.com>
To: 32257 <at> debbugs.gnu.org
Cc: lars ingebrigtsen <larsi <at> gnus.org>, andy moreton <andrewjmoreton <at> gmail.com>
Subject: Re: bug#32257: 26.1; read-multiple-choice inf loops on mouse clicks
Date: Wed, 25 Jul 2018 21:25:46 -0400

Noam Postavsky <npostavs <at> gmail.com> writes:

> X-Debbugs-CC: Andy Moreton <andrewjmoreton <at> gmail.com>, Lars Ingebrigtsen <larsi <at> gnus.org>
>
> Starting from emacs -Q, evaluate:
>
>     (require 'rmc)
>     (read-multiple-choice "choice? " '((?a "ay") (?b "bee") (?c "see")))
>
> then click the mouse somewhere instead of answering the prompt, notice
> Emacs maxing out CPU, hit C-g.  *Messages* will have a log of the prompt
> being repeated many times:
>
>     choice?  (ay, bee, [c] see, ?):  [4435 times]

The problem seems to be that read-char doesn't "use up" non-character
events, e.g., with the following:

(defun read-char-or-err ()
  (condition-case err
      (read-char)
    (error err)))

(list (read-char-or-err)
      (read-char-or-err)
      (read-char-or-err)
      (read-char-or-err)
      (read-char-or-err))

this returns ((error "Non-character input-event") (error "Non-character
input-event") ...) regardless of how many calls to read-char-or-err
there are.

The patch below fixes the inf looping, although it still doesn't allow
any other user interaction (unlike read-from-minibuffer).

--- i/lisp/emacs-lisp/rmc.el
+++ w/lisp/emacs-lisp/rmc.el
@@ -118,8 +118,10 @@ read-multiple-choice
                             choices)))
                   (condition-case nil
                       (let ((cursor-in-echo-area t))
-                        (read-char))
+                        (read-event))
                     (error nil))))
+          (unless (characterp tchar)
+            (setq tchar nil))
           (setq answer (lookup-key query-replace-map (vector tchar) t))
           (setq tchar
                 (cond

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Noam Postavsky <npostavs <at> gmail.com>
Cc: andrewjmoreton <at> gmail.com, larsi <at> gnus.org, 32257 <at> debbugs.gnu.org
Subject: Re: bug#32257: 26.1; read-multiple-choice inf loops on mouse clicks
Date: Fri, 27 Jul 2018 12:08:58 +0300

> From: Noam Postavsky <npostavs <at> gmail.com>
> Date: Wed, 25 Jul 2018 21:25:46 -0400
> Cc: lars ingebrigtsen <larsi <at> gnus.org>, andy moreton <andrewjmoreton <at> gmail.com>
> > Starting from emacs -Q, evaluate:
> >
> >     (require 'rmc)
> >     (read-multiple-choice "choice? " '((?a "ay") (?b "bee") (?c "see")))
> >
> > then click the mouse somewhere instead of answering the prompt, notice
> > Emacs maxing out CPU, hit C-g.  *Messages* will have a log of the prompt
> > being repeated many times:
> >
> >     choice?  (ay, bee, [c] see, ?):  [4435 times]
> 
> The problem seems to be that read-char doesn't "use up" non-character
> events, e.g., with the following:
> 
> (defun read-char-or-err ()
>   (condition-case err
>       (read-char)
>     (error err)))
> 
> (list (read-char-or-err)
>       (read-char-or-err)
>       (read-char-or-err)
>       (read-char-or-err)
>       (read-char-or-err))
> 
> this returns ((error "Non-character input-event") (error "Non-character
> input-event") ...) regardless of how many calls to read-char-or-err
> there are.
> 
> The patch below fixes the inf looping, although it still doesn't allow
> any other user interaction (unlike read-from-minibuffer).

If we want this change on emacs-26, we should carefully audit all the
other users of rmc.el (and in generally, I'd prefer some more local
change in nsm.el on the release branch).  We've had our share of
subtle bugs introduced by switching to an "almost-compatible" method
of reading input.

Thanks.

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

From: Andy Moreton <andrewjmoreton <at> gmail.com>
To: bug-gnu-emacs <at> gnu.org
Subject: Re: bug#32257: 26.1; read-multiple-choice inf loops on mouse clicks
Date: Fri, 27 Jul 2018 12:35:27 +0100

On Fri 27 Jul 2018, Eli Zaretskii wrote:

>> From: Noam Postavsky <npostavs <at> gmail.com>
>> Date: Wed, 25 Jul 2018 21:25:46 -0400
>> Cc: lars ingebrigtsen <larsi <at> gnus.org>, andy moreton <andrewjmoreton <at> gmail.com>
>> > Starting from emacs -Q, evaluate:
>> >
>> >     (require 'rmc)
>> >     (read-multiple-choice "choice? " '((?a "ay") (?b "bee") (?c "see")))
>> >
>> > then click the mouse somewhere instead of answering the prompt, notice
>> > Emacs maxing out CPU, hit C-g.  *Messages* will have a log of the prompt
>> > being repeated many times:
>> >
>> >     choice?  (ay, bee, [c] see, ?):  [4435 times]
>> 
>> The problem seems to be that read-char doesn't "use up" non-character
>> events, e.g., with the following:
>> 
>> (defun read-char-or-err ()
>>   (condition-case err
>>       (read-char)
>>     (error err)))
>> 
>> (list (read-char-or-err)
>>       (read-char-or-err)
>>       (read-char-or-err)
>>       (read-char-or-err)
>>       (read-char-or-err))
>> 
>> this returns ((error "Non-character input-event") (error "Non-character
>> input-event") ...) regardless of how many calls to read-char-or-err
>> there are.
>> 
>> The patch below fixes the inf looping, although it still doesn't allow
>> any other user interaction (unlike read-from-minibuffer).

I've tested this on emacs-26, and it fixes the original problem from NSM
that resulted in this bug report.

> If we want this change on emacs-26, we should carefully audit all the
> other users of rmc.el (and in generally, I'd prefer some more local
> change in nsm.el on the release branch).  We've had our share of
> subtle bugs introduced by switching to an "almost-compatible" method
> of reading input.

read-multiple choice only has two callers (`nsm-query-user' and
`message-fix-before-sending') in both master and emacs-26.

While I understand caution over changes to emacs-26, the only place that
needs fixing is read-multiple-choice. It seems odd to prefer changes
in its callers, that will more likely introduce additional bugs without
fixing the original issue.

    AndyM

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Andy Moreton <andrewjmoreton <at> gmail.com>
Cc: 32257 <at> debbugs.gnu.org
Subject: Re: bug#32257: 26.1; read-multiple-choice inf loops on mouse clicks
Date: Fri, 27 Jul 2018 15:30:33 +0300

> From: Andy Moreton <andrewjmoreton <at> gmail.com>
> Date: Fri, 27 Jul 2018 12:35:27 +0100
> 
> > If we want this change on emacs-26, we should carefully audit all the
> > other users of rmc.el (and in generally, I'd prefer some more local
> > change in nsm.el on the release branch).  We've had our share of
> > subtle bugs introduced by switching to an "almost-compatible" method
> > of reading input.
> 
> read-multiple choice only has two callers (`nsm-query-user' and
> `message-fix-before-sending') in both master and emacs-26.

In Emacs, yes.  But what about the world out there?

> While I understand caution over changes to emacs-26, the only place that
> needs fixing is read-multiple-choice. It seems odd to prefer changes
> in its callers, that will more likely introduce additional bugs without
> fixing the original issue.

In case it wasn't clear I meant to make a safer change on emacs-26,
and change read-multiple-choice on master.

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

From: Noam Postavsky <npostavs <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 32257 <at> debbugs.gnu.org, Andy Moreton <andrewjmoreton <at> gmail.com>
Subject: Re: bug#32257: 26.1; read-multiple-choice inf loops on mouse clicks
Date: Fri, 27 Jul 2018 08:45:03 -0400

Eli Zaretskii <eliz <at> gnu.org> writes:

>> From: Andy Moreton <andrewjmoreton <at> gmail.com>
>> Date: Fri, 27 Jul 2018 12:35:27 +0100
>> 
>> > If we want this change on emacs-26, we should carefully audit all the
>> > other users of rmc.el

What should we check for though?

>> > (and in generally, I'd prefer some more local
>> > change in nsm.el on the release branch).  We've had our share of
>> > subtle bugs introduced by switching to an "almost-compatible" method
>> > of reading input.
>> 
>> read-multiple choice only has two callers (`nsm-query-user' and
>> `message-fix-before-sending') in both master and emacs-26.
>
> In Emacs, yes.  But what about the world out there?

I expect all the callers out in the world will exhibit the same bug.

> In case it wasn't clear I meant to make a safer change on emacs-26,
> and change read-multiple-choice on master.

At any rate, I don't see a way of fixing it in the caller, short of
temporarily fsetting read-char into read-event.  Also,
read-multiple-choice is new in Emacs 26, so it seems to me we should
rather fix it in 26.2.

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Noam Postavsky <npostavs <at> gmail.com>
Cc: 32257 <at> debbugs.gnu.org, andrewjmoreton <at> gmail.com
Subject: Re: bug#32257: 26.1; read-multiple-choice inf loops on mouse clicks
Date: Fri, 27 Jul 2018 16:50:02 +0300

> From: Noam Postavsky <npostavs <at> gmail.com>
> Cc: Andy Moreton <andrewjmoreton <at> gmail.com>,  32257 <at> debbugs.gnu.org
> Date: Fri, 27 Jul 2018 08:45:03 -0400
> 
> Eli Zaretskii <eliz <at> gnu.org> writes:
> 
> >> From: Andy Moreton <andrewjmoreton <at> gmail.com>
> >> Date: Fri, 27 Jul 2018 12:35:27 +0100
> >> 
> >> > If we want this change on emacs-26, we should carefully audit all the
> >> > other users of rmc.el
> 
> What should we check for though?

Anything that read-event handles differently from read-char.  Maybe a
good starting point is to compile a list of the differences in
behavior between the two.

> >> read-multiple choice only has two callers (`nsm-query-user' and
> >> `message-fix-before-sending') in both master and emacs-26.
> >
> > In Emacs, yes.  But what about the world out there?
> 
> I expect all the callers out in the world will exhibit the same bug.

What about the features they expect?

> At any rate, I don't see a way of fixing it in the caller, short of
> temporarily fsetting read-char into read-event.

If there's no better idea, we could copy read-multiple-choice into
nsm.el and replace read-char with read-event there.  But maybe there
are more elegant ideas.

> Also, read-multiple-choice is new in Emacs 26, so it seems to me we
> should rather fix it in 26.2.

I agree, I just am not convince that replacing read-char with
read-event is the right fix.

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

From: Noam Postavsky <npostavs <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: andrewjmoreton <at> gmail.com, 32257 <at> debbugs.gnu.org
Subject: Re: bug#32257: 26.1; read-multiple-choice inf loops on mouse clicks
Date: Mon, 30 Jul 2018 21:52:40 -0400

Eli Zaretskii <eliz <at> gnu.org> writes:

>> >> > If we want this change on emacs-26, we should carefully audit all the
>> >> > other users of rmc.el
>> 
>> What should we check for though?
>
> Anything that read-event handles differently from read-char.  Maybe a
> good starting point is to compile a list of the differences in
> behavior between the two.

Looking at the implementation, they both delegate to
read_filtered_event, but read-char passes 1 for the first three args,
where read-event passes 0.

   If NO_SWITCH_FRAME, switch-frame events are stashed
   until we get a character we like, and then stuffed into
   unread_switch_frame.

   If ASCII_REQUIRED, check function key events to see
   if the unmodified version of the symbol has a Qascii_character
   property, and use that character, if present.

   If ERROR_NONASCII, signal an error if the input we
   get isn't an ASCII character with modifiers.  If it's false but
   ASCII_REQUIRED is true, just re-read until we get an ASCII
   character.

Another possibility is to use read-char-exclusive which only changes
ERROR_NON_ASCII to 0.  The downside is that when there are mouse clicks
it prints the events into the minibuffer, covering the prompt (but
typing "?"  still works to restore the prompt).

--- i/lisp/emacs-lisp/rmc.el
+++ w/lisp/emacs-lisp/rmc.el
@@ -118,7 +118,7 @@ read-multiple-choice
                             choices)))
                   (condition-case nil
                       (let ((cursor-in-echo-area t))
-                        (read-char))
+                        (read-char-exclusive))
                     (error nil))))
           (setq answer (lookup-key query-replace-map (vector tchar) t))
           (setq tchar

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

From: Andy Moreton <andrewjmoreton <at> gmail.com>
To: bug-gnu-emacs <at> gnu.org
Subject: Re: bug#32257: 26.1; read-multiple-choice inf loops on mouse clicks
Date: Tue, 31 Jul 2018 12:59:37 +0100

On Mon 30 Jul 2018, Noam Postavsky wrote:

> Eli Zaretskii <eliz <at> gnu.org> writes:
>
>>> >> > If we want this change on emacs-26, we should carefully audit all the
>>> >> > other users of rmc.el
>>> 
>>> What should we check for though?
>>
>> Anything that read-event handles differently from read-char.  Maybe a
>> good starting point is to compile a list of the differences in
>> behavior between the two.
>
> Looking at the implementation, they both delegate to
> read_filtered_event, but read-char passes 1 for the first three args,
> where read-event passes 0.
>
>    If NO_SWITCH_FRAME, switch-frame events are stashed
>    until we get a character we like, and then stuffed into
>    unread_switch_frame.
>
>    If ASCII_REQUIRED, check function key events to see
>    if the unmodified version of the symbol has a Qascii_character
>    property, and use that character, if present.
>
>    If ERROR_NONASCII, signal an error if the input we
>    get isn't an ASCII character with modifiers.  If it's false but
>    ASCII_REQUIRED is true, just re-read until we get an ASCII
>    character.

So perhaps this `read-char' to `read-event' change will result in different
frame switching behaviour. I'm not sure how to test that though.

> Another possibility is to use read-char-exclusive which only changes
> ERROR_NON_ASCII to 0.  The downside is that when there are mouse clicks
> it prints the events into the minibuffer, covering the prompt (but
> typing "?"  still works to restore the prompt).

AS you have done, I read the implementation and tried a patch using
`read-char-exclusive'. The result is unusable as the printed events
obscure the original question.

The proper long term fix for this is to make read-multiple-choice use a
dedicated buffer rather than the minibuffer, and give better visibility
when more than one question is asked in succession. Perhaps also some
way to stop the echo area from obscuring the minibuffer ?

    AndyM

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

From: martin rudalics <rudalics <at> gmx.at>
To: Andy Moreton <andrewjmoreton <at> gmail.com>, 32257 <at> debbugs.gnu.org
Subject: Re: bug#32257: 26.1; read-multiple-choice inf loops on mouse clicks
Date: Tue, 31 Jul 2018 14:27:14 +0200

> Perhaps also some
> way to stop the echo area from obscuring the minibuffer ?

Here I use separate echo (area) and minibuffer windows.  If you want
to play around with a patch please tell me.

martin

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

From: Andy Moreton <andrewjmoreton <at> gmail.com>
To: bug-gnu-emacs <at> gnu.org
Subject: Re: bug#32257: 26.1; read-multiple-choice inf loops on mouse clicks
Date: Tue, 31 Jul 2018 13:38:33 +0100

On Tue 31 Jul 2018, martin rudalics wrote:

>> Perhaps also some
>> way to stop the echo area from obscuring the minibuffer ?
>
> Here I use separate echo (area) and minibuffer windows.  If you want
> to play around with a patch please tell me.
>
> martin

Yes please - prefeably in a new bug report for the enhancement patch,
so it can be tracked separately from this bug.

Thanks,

    AndyM

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Noam Postavsky <npostavs <at> gmail.com>
Cc: andrewjmoreton <at> gmail.com, 32257 <at> debbugs.gnu.org
Subject: Re: bug#32257: 26.1; read-multiple-choice inf loops on mouse clicks
Date: Tue, 31 Jul 2018 19:04:07 +0300

> From: Noam Postavsky <npostavs <at> gmail.com>
> Cc: 32257 <at> debbugs.gnu.org,  andrewjmoreton <at> gmail.com
> Date: Mon, 30 Jul 2018 21:52:40 -0400
> 
> Another possibility is to use read-char-exclusive which only changes
> ERROR_NON_ASCII to 0.  The downside is that when there are mouse clicks
> it prints the events into the minibuffer, covering the prompt (but
> typing "?"  still works to restore the prompt).
> 
> --- i/lisp/emacs-lisp/rmc.el
> +++ w/lisp/emacs-lisp/rmc.el
> @@ -118,7 +118,7 @@ read-multiple-choice
>                              choices)))
>                    (condition-case nil
>                        (let ((cursor-in-echo-area t))
> -                        (read-char))
> +                        (read-char-exclusive))
>                      (error nil))))
>            (setq answer (lookup-key query-replace-map (vector tchar) t))
>            (setq tchar

Maybe this is the best compromise for emacs-026.  We could search for
a better (and bolder) solution on master.

Thanks.

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Andy Moreton <andrewjmoreton <at> gmail.com>
Cc: 32257 <at> debbugs.gnu.org
Subject: Re: bug#32257: 26.1; read-multiple-choice inf loops on mouse clicks
Date: Tue, 31 Jul 2018 19:06:29 +0300

> From: Andy Moreton <andrewjmoreton <at> gmail.com>
> Date: Tue, 31 Jul 2018 12:59:37 +0100
> 
> > Another possibility is to use read-char-exclusive which only changes
> > ERROR_NON_ASCII to 0.  The downside is that when there are mouse clicks
> > it prints the events into the minibuffer, covering the prompt (but
> > typing "?"  still works to restore the prompt).
> 
> AS you have done, I read the implementation and tried a patch using
> `read-char-exclusive'. The result is unusable as the printed events
> obscure the original question.

I think "unusable" is an exaggeration, since you can recover the
prompt.  And the result is definitely better than the current
situation, where you just get stuck.

> The proper long term fix for this is to make read-multiple-choice use a
> dedicated buffer rather than the minibuffer, and give better visibility
> when more than one question is asked in succession. Perhaps also some
> way to stop the echo area from obscuring the minibuffer ?

The echo-area messages are fine, but we should have a feature that
allows to suppress echoing the mouse clicks.

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

From: Andy Moreton <andrewjmoreton <at> gmail.com>
To: bug-gnu-emacs <at> gnu.org
Subject: Re: bug#32257: 26.1; read-multiple-choice inf loops on mouse clicks
Date: Tue, 31 Jul 2018 20:26:33 +0100

On Tue 31 Jul 2018, Eli Zaretskii wrote:

>> From: Andy Moreton <andrewjmoreton <at> gmail.com>
>> Date: Tue, 31 Jul 2018 12:59:37 +0100
>> 
>> > Another possibility is to use read-char-exclusive which only changes
>> > ERROR_NON_ASCII to 0.  The downside is that when there are mouse clicks
>> > it prints the events into the minibuffer, covering the prompt (but
>> > typing "?"  still works to restore the prompt).
>> 
>> AS you have done, I read the implementation and tried a patch using
>> `read-char-exclusive'. The result is unusable as the printed events
>> obscure the original question.
>
> I think "unusable" is an exaggeration, since you can recover the
> prompt.  And the result is definitely better than the current
> situation, where you just get stuck.

No. It is is just as unusable, as the only way to get past the stream of
event message hiding the question you are trying to answer is to hit ^G
until it goes away. Using `read-char-exclusive' does not make any improvement on the
original problem.

We already have a working patch that solves the original problem.

>> The proper long term fix for this is to make read-multiple-choice use a
>> dedicated buffer rather than the minibuffer, and give better visibility
>> when more than one question is asked in succession. Perhaps also some
>> way to stop the echo area from obscuring the minibuffer ?
>
> The echo-area messages are fine, but we should have a feature that
> allows to suppress echoing the mouse clicks.

They are a pain if you are asked more than one question, but the echo
area message gets in the way of the minibuffer prompt that you need to
read in order to answer the question.

    AndyM

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

From: Andy Moreton <andrewjmoreton <at> gmail.com>
To: bug-gnu-emacs <at> gnu.org
Subject: Re: bug#32257: 26.1; read-multiple-choice inf loops on mouse clicks
Date: Tue, 31 Jul 2018 20:29:31 +0100

On Tue 31 Jul 2018, Eli Zaretskii wrote:

>> From: Noam Postavsky <npostavs <at> gmail.com>
>> Cc: 32257 <at> debbugs.gnu.org,  andrewjmoreton <at> gmail.com
>> Date: Mon, 30 Jul 2018 21:52:40 -0400
>> 
>> Another possibility is to use read-char-exclusive which only changes
>> ERROR_NON_ASCII to 0.  The downside is that when there are mouse clicks
>> it prints the events into the minibuffer, covering the prompt (but
>> typing "?"  still works to restore the prompt).

Only if you know in advance that typing "?" will do that.

>> --- i/lisp/emacs-lisp/rmc.el
>> +++ w/lisp/emacs-lisp/rmc.el
>> @@ -118,7 +118,7 @@ read-multiple-choice
>>                              choices)))
>>                    (condition-case nil
>>                        (let ((cursor-in-echo-area t))
>> -                        (read-char))
>> +                        (read-char-exclusive))
>>                      (error nil))))
>>            (setq answer (lookup-key query-replace-map (vector tchar) t))
>>            (setq tchar
>
> Maybe this is the best compromise for emacs-026.  We could search for
> a better (and bolder) solution on master.

This is no better than the status quo. Noam's original patch may bring
some possibility of new problems, but it does at least fix the original
problem (on emacs-26 and master).

    AndyM

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Andy Moreton <andrewjmoreton <at> gmail.com>
Cc: 32257 <at> debbugs.gnu.org
Subject: Re: bug#32257: 26.1; read-multiple-choice inf loops on mouse clicks
Date: Wed, 01 Aug 2018 08:27:54 +0300

> From: Andy Moreton <andrewjmoreton <at> gmail.com>
> Date: Tue, 31 Jul 2018 20:26:33 +0100
> 
> > I think "unusable" is an exaggeration, since you can recover the
> > prompt.  And the result is definitely better than the current
> > situation, where you just get stuck.
> 
> No. It is is just as unusable, as the only way to get past the stream of
> event message hiding the question you are trying to answer is to hit ^G
> until it goes away. Using `read-char-exclusive' does not make any improvement on the
> original problem.

It is here, because typing ? brings back the original prompt, as does
any other character.  So I still think you are exaggerating.

> > The echo-area messages are fine, but we should have a feature that
> > allows to suppress echoing the mouse clicks.
> 
> They are a pain if you are asked more than one question, but the echo
> area message gets in the way of the minibuffer prompt that you need to
> read in order to answer the question.

Echo area messages in general go away to reveal the prompt.  The only
problem in this case is with the echo for mouse clicks, AFAICT.

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Andy Moreton <andrewjmoreton <at> gmail.com>
Cc: 32257 <at> debbugs.gnu.org
Subject: Re: bug#32257: 26.1; read-multiple-choice inf loops on mouse clicks
Date: Wed, 01 Aug 2018 08:29:17 +0300

> From: Andy Moreton <andrewjmoreton <at> gmail.com>
> Date: Tue, 31 Jul 2018 20:29:31 +0100
> 
> Noam's original patch may bring some possibility of new problems,
> but it does at least fix the original problem (on emacs-26 and
> master).

Fixing a problem and introducing another doesn't sound wise to me.
We've been there several times during the last years, and I don't want
to make the same mistake again.  Sorry.

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

From: martin rudalics <rudalics <at> gmx.at>
To: Andy Moreton <andrewjmoreton <at> gmail.com>, 32257 <at> debbugs.gnu.org
Subject: Re: bug#32257: 26.1; read-multiple-choice inf loops on mouse clicks
Date: Wed, 01 Aug 2018 10:44:18 +0200

[Message part 1 (text/plain, inline)]

>> Here I use separate echo (area) and minibuffer windows.  If you want
>> to play around with a patch please tell me.
>>
>> martin
>
> Yes please - prefeably in a new bug report for the enhancement patch,
> so it can be tracked separately from this bug.

It's not yet ready for broader discussion.  I attach it here so you
can just test whether making the echo interference go away during
the minibuffer dialog.

To put it into use run emacs with

(setq default-frame-alist '((minibuffer . loose) (echo-area . t)))

Looks better with window dividers enabled.

Eventually I'll make a remote branch.  But this may take its time.

martin

[echomini.diff (text/plain, attachment)]

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

From: Andy Moreton <andrewjmoreton <at> gmail.com>
To: bug-gnu-emacs <at> gnu.org
Subject: Re: bug#32257: 26.1; read-multiple-choice inf loops on mouse clicks
Date: Wed, 01 Aug 2018 13:05:12 +0100

On Wed 01 Aug 2018, Eli Zaretskii wrote:

>> From: Andy Moreton <andrewjmoreton <at> gmail.com>
>> Date: Tue, 31 Jul 2018 20:29:31 +0100
>> 
>> Noam's original patch may bring some possibility of new problems,
>> but it does at least fix the original problem (on emacs-26 and
>> master).
>
> Fixing a problem and introducing another doesn't sound wise to me.
> We've been there several times during the last years, and I don't want
> to make the same mistake again.  Sorry.

Perhaps reverting the patches that introduced read-multiple-choice
is the right answer then.

    AndyM

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

From: Noam Postavsky <npostavs <at> gmail.com>
To: martin rudalics <rudalics <at> gmx.at>
Cc: 32257 <at> debbugs.gnu.org, Andy Moreton <andrewjmoreton <at> gmail.com>
Subject: Re: bug#32257: 26.1; read-multiple-choice inf loops on mouse clicks
Date: Wed, 01 Aug 2018 08:30:15 -0400

martin rudalics <rudalics <at> gmx.at> writes:

>> Yes please - prefeably in a new bug report for the enhancement patch,
>> so it can be tracked separately from this bug.
>
> It's not yet ready for broader discussion.  I attach it here so you
> can just test whether making the echo interference go away during
> the minibuffer dialog.

By the way, there is the existing Bug#19718 about the minibuffer
interference during read_filtered_event.

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

From: Robert Pluim <rpluim <at> gmail.com>
To: martin rudalics <rudalics <at> gmx.at>
Cc: 32257 <at> debbugs.gnu.org, Andy Moreton <andrewjmoreton <at> gmail.com>
Subject: Re: bug#32257: 26.1; read-multiple-choice inf loops on mouse clicks
Date: Wed, 01 Aug 2018 14:57:26 +0200

martin rudalics <rudalics <at> gmx.at> writes:

>>> Here I use separate echo (area) and minibuffer windows.  If you want
>>> to play around with a patch please tell me.
>>>
>>> martin
>>
>> Yes please - prefeably in a new bug report for the enhancement patch,
>> so it can be tracked separately from this bug.
>
> It's not yet ready for broader discussion.  I attach it here so you
> can just test whether making the echo interference go away during
> the minibuffer dialog.
>
> To put it into use run emacs with
>
> (setq default-frame-alist '((minibuffer . loose) (echo-area . t)))
>
> Looks better with window dividers enabled.
>
> Eventually I'll make a remote branch.  But this may take its time.

It looks interesting, but please use something other than 'loose' to
describe the behaviour. I guess 'dedicated' is already
overloaded. 'separate', 'no-echo'....?

Robert

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

From: Live System User <nyc4bos <at> aol.com>
To: bug-gnu-emacs <at> gnu.org
Subject: Re: bug#32257: 26.1; read-multiple-choice inf loops on mouse clicks
Date: Wed, 01 Aug 2018 16:55:14 -0400

[Message part 1 (text/plain, inline)]

martin rudalics <rudalics <at> gmx.at> writes:

>>> Here I use separate echo (area) and minibuffer windows.  If you want
>>> to play around with a patch please tell me.
>>>
>>> martin
>>
>> Yes please - prefeably in a new bug report for the enhancement patch,
>> so it can be tracked separately from this bug.
>
> It's not yet ready for broader discussion.  I attach it here so you
> can just test whether making the echo interference go away during
> the minibuffer dialog.

  I know this is not ready but I thought I'd report this error
  when using this patch with popwin.el (a third-party app).

  Thanks.

[echomini-error.txt (text/plain, attachment)]

[Message part 3 (text/plain, inline)]

>
> To put it into use run emacs with
>
> (setq default-frame-alist '((minibuffer . loose) (echo-area . t)))
>
> Looks better with window dividers enabled.
>
> Eventually I'll make a remote branch.  But this may take its time.
>
> martin

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

From: martin rudalics <rudalics <at> gmx.at>
To: Robert Pluim <rpluim <at> gmail.com>
Cc: 32257 <at> debbugs.gnu.org, Andy Moreton <andrewjmoreton <at> gmail.com>
Subject: Re: bug#32257: 26.1; read-multiple-choice inf loops on mouse clicks
Date: Thu, 02 Aug 2018 09:09:33 +0200

> It looks interesting, but please use something other than 'loose' to
> describe the behaviour. I guess 'dedicated' is already
> overloaded. 'separate', 'no-echo'....?

The behavior is more complicated than that.  In escalating order a
user can:

(1) Put minibuffer and echo in a shared "fixed" window at the top of
the frame.  Together with the standard behavior, this is considered a
fixed minibuffer window because it never goes away.

(2) Put minibuffer and echo in a shared "loose" window anywhere on a
frame.  A loose window is not fixed, it can be deleted at any time and
will be recreated when a message shall be shown or a question asked.

(3) Put minibuffer and echo in separate, loose windows anywhere on a
frame.  Both windows can be deleted where the minibuffer window is
deleted automatically when the dialog with the user has terminated.

Hence, the term loose refers only to the fact that such a window can
be deleted and will be recreated on-the-fly.  Alternatively, we could
call such a window "volatile", "ephemeral" ...  And to indicate that
echos shall appear in a separate window you have to specify a non-nil
'echo-area' frame parameter on top of a 'loose' minibuffer parameter.

Eventually we would allow an arbitrary number of loose minibuffer and
echo windows on a frame, each possibly owned by a separate thread
allowing an arbitrary number of user interactions to go on in
parallel.  But I have not yet digged into all conventions for
minibuffers and echos (naming, synchronicity) and maybe never will.

martin

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

From: martin rudalics <rudalics <at> gmx.at>
To: Live System User <nyc4bos <at> aol.com>, 32257 <at> debbugs.gnu.org
Subject: Re: bug#32257: 26.1; read-multiple-choice inf loops on mouse clicks
Date: Thu, 02 Aug 2018 09:09:57 +0200

>    I know this is not ready but I thought I'd report this error
>    when using this patch with popwin.el (a third-party app).

FWIW this is a bug in popwin.el and should be fixed there.  The same
error is reported here with Emacs 26 invoked via

--eval "(setq default-frame-alist '((minibuffer . nil)))"

martin

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

From: Noam Postavsky <npostavs <at> gmail.com>
To: Andy Moreton <andrewjmoreton <at> gmail.com>
Cc: 32257 <at> debbugs.gnu.org
Subject: Re: bug#32257: 26.1; read-multiple-choice inf loops on mouse clicks
Date: Tue, 21 May 2019 20:52:34 -0400

[Message part 1 (text/plain, inline)]

tags 32257 + patch
quit

Andy Moreton <andrewjmoreton <at> gmail.com> writes:

> On Wed 01 Aug 2018, Eli Zaretskii wrote:
>>> 
>>> Noam's original patch may bring some possibility of new problems,
>>> but it does at least fix the original problem (on emacs-26 and
>>> master).
>>
>> Fixing a problem and introducing another doesn't sound wise to me.
>> We've been there several times during the last years, and I don't want
>> to make the same mistake again.  Sorry.
>
> Perhaps reverting the patches that introduced read-multiple-choice
> is the right answer then.

How about for emacs-26, we call read-event only after receiving the
problematic error.  This works around the problem, and should be safe
enough, since it only triggers when we would otherwise be ending up in
an infloop anyway.

[0001-Avoid-infloop-in-read-multiple-choice-Bug-32257.patch (text/x-diff, inline)]

From 8545e36df343cc169d7ae1ab3a43c9805cd51015 Mon Sep 17 00:00:00 2001
From: Noam Postavsky <npostavs <at> gmail.com>
Date: Tue, 21 May 2019 20:33:09 -0400
Subject: [PATCH] Avoid infloop in read-multiple-choice (Bug#32257)

* lisp/emacs-lisp/rmc.el (read-multiple-choice): When `read-char'
signals an error "Non-character input-event", call `read-event' to
take the non-character event out of the queue.  Don't merge to master,
we just use `read-event' directly there, rather than this solution
which relies a particular error message.
---
 lisp/emacs-lisp/rmc.el | 9 +++++++--
 1 file changed, 7 insertions(+), 2 deletions(-)

diff --git a/lisp/emacs-lisp/rmc.el b/lisp/emacs-lisp/rmc.el
index 6d1adae974..5411f2ba77 100644
--- a/lisp/emacs-lisp/rmc.el
+++ b/lisp/emacs-lisp/rmc.el
@@ -116,10 +116,15 @@ read-multiple-choice
                               (cons (capitalize (cadr elem))
                                     (car elem)))
                             choices)))
-                  (condition-case nil
+                  (condition-case err
                       (let ((cursor-in-echo-area t))
                         (read-char))
-                    (error nil))))
+                    (error (when (equal (cadr err) "Non-character input-event")
+                             ;; Use up the non-character input-event.
+                             ;; Otherwise we'll just keep reading it
+                             ;; again and again (Bug#32257).
+                             (read-event))
+                           nil))))
           (setq answer (lookup-key query-replace-map (vector tchar) t))
           (setq tchar
                 (cond
-- 
2.11.0

[Message part 3 (text/plain, inline)]

And master can just use read-event.

[0001-Avoid-infloop-in-read-multiple-choice-Bug-32257.patch (text/x-diff, inline)]

From f1f32043f65dc19b6d63cf1ce52ef19b46c14e22 Mon Sep 17 00:00:00 2001
From: Noam Postavsky <npostavs <at> gmail.com>
Date: Tue, 21 May 2019 20:38:00 -0400
Subject: [PATCH] Avoid infloop in read-multiple-choice (Bug#32257)

* lisp/emacs-lisp/rmc.el (read-multiple-choice): Use `read-event'
which won't get stuck (return the same event over and over again) for
non-character events, unlike `read-char'.
---
 lisp/emacs-lisp/rmc.el | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/lisp/emacs-lisp/rmc.el b/lisp/emacs-lisp/rmc.el
index 6d1adae974..47f3b8dc9c 100644
--- a/lisp/emacs-lisp/rmc.el
+++ b/lisp/emacs-lisp/rmc.el
@@ -118,7 +118,7 @@ read-multiple-choice
                             choices)))
                   (condition-case nil
                       (let ((cursor-in-echo-area t))
-                        (read-char))
+                        (read-event))
                     (error nil))))
           (setq answer (lookup-key query-replace-map (vector tchar) t))
           (setq tchar
-- 
2.11.0

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Noam Postavsky <npostavs <at> gmail.com>
Cc: 32257 <at> debbugs.gnu.org, andrewjmoreton <at> gmail.com
Subject: Re: bug#32257: 26.1; read-multiple-choice inf loops on mouse clicks
Date: Wed, 22 May 2019 13:08:47 +0300

> From: Noam Postavsky <npostavs <at> gmail.com>
> Date: Tue, 21 May 2019 20:52:34 -0400
> Cc: 32257 <at> debbugs.gnu.org
> 
> >> Fixing a problem and introducing another doesn't sound wise to me.
> >> We've been there several times during the last years, and I don't want
> >> to make the same mistake again.  Sorry.
> >
> > Perhaps reverting the patches that introduced read-multiple-choice
> > is the right answer then.
> 
> How about for emacs-26, we call read-event only after receiving the
> problematic error.  This works around the problem, and should be safe
> enough, since it only triggers when we would otherwise be ending up in
> an infloop anyway.

SGTM, thanks.

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

From: Noam Postavsky <npostavs <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: andrewjmoreton <at> gmail.com, 32257 <at> debbugs.gnu.org
Subject: Re: bug#32257: 26.1; read-multiple-choice inf loops on mouse clicks
Date: Sun, 26 May 2019 08:57:34 -0400

tags 32257 fixed
close 32257 26.3
quit

Eli Zaretskii <eliz <at> gnu.org> writes:

>> How about for emacs-26, we call read-event only after receiving the
>> problematic error.  This works around the problem, and should be safe
>> enough, since it only triggers when we would otherwise be ending up in
>> an infloop anyway.
>
> SGTM, thanks.

Done.

c4d4dcf17e 2019-05-26T08:46:30-04:00 "Avoid infloop in read-multiple-choice (Bug#32257)"
https://git.savannah.gnu.org/cgit/emacs.git/commit/?id=c4d4dcf17e407a3c68e150f22b9756ef6c943070

3f03f6284a 2019-05-26T08:16:23-04:00 "Avoid infloop in read-multiple-choice (Bug#32257)"
https://git.savannah.gnu.org/cgit/emacs.git/commit/?id=3f03f6284a093d69086773226bc2273cf62f5e85

Previous Next

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