GNU bug report logs - #19718
read_filtered_event echos mouse events until character is inputted

Previous Next

To reply to this bug, email your comments to 19718 AT debbugs.gnu.org.

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

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

From: Nick Andryshak <nandryshak <at> gmail.com>
To: bug-gnu-emacs <at> gnu.org
Subject: read_filtered_event echos mouse events until character is inputted
Date: Wed, 28 Jan 2015 15:35:43 -0500

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

See this Stack Exchange question:

http://emacs.stackexchange.com/questions/7443/mouse-problem-in-org-mode-export-window

The asker is trying to use the mouse wheel to scroll the org-export-dispatch
window. org-export-dispatch is using the built-in function
read-char-exclusive,
which in turn calls read_filtered_event with the parameter error_nonascii
set to
0. Unlike read-char, which will throw an error upon receiving a mouse event,
read-char-exclusive just keeps retrying, and eventually the echo area will
become full of mouse event names.

Here's the git diff of a small, possible fix for this issue:

$ git diff
diff --git a/src/lread.c b/src/lread.c
index 69ec059..0041b03 100644
--- a/src/lread.c
+++ b/src/lread.c
@@ -651,7 +651,10 @@ read_filtered_event (bool no_switch_frame, bool
ascii_required,
              error ("Non-character input-event");
            }
          else
-           goto retry;
+            {
+              message1 (0);
+              goto retry;
+            }
        }
     }


Nick Andryshak

[Message part 2 (text/html, inline)]

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

From: Noam Postavsky <npostavs <at> gmail.com>
To: Nick Andryshak <nandryshak <at> gmail.com>
Cc: 19718 <at> debbugs.gnu.org
Subject: Re: bug#19718: read_filtered_event echos mouse events until character
 is inputted
Date: Mon, 14 May 2018 22:43:17 -0400

severity 19718 minor
quit

Nick Andryshak <nandryshak <at> gmail.com> writes:

> --- a/src/lread.c
> +++ b/src/lread.c
> @@ -651,7 +651,10 @@ read_filtered_event (bool no_switch_frame, bool ascii_required,
>               error ("Non-character input-event");
>             }
>           else
> -           goto retry;
> +            {
> +              message1 (0);
> +              goto retry;
> +            }

Hmm, it doesn't quite work.  The minibuffer is blanked, but if I wait a
second or two, then the all those mouse events show up again.

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

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: Nick Andryshak <nandryshak <at> gmail.com>
Cc: 19718 <at> debbugs.gnu.org
Subject: Re: bug#19718: read_filtered_event echos mouse events until
 character is inputted
Date: Tue, 25 Aug 2020 11:54:21 +0200

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

Nick Andryshak <nandryshak <at> gmail.com> writes:

> See this Stack Exchange question: 
>
> http://emacs.stackexchange.com/questions/7443/mouse-problem-in-org-mode-export-window
>
> The asker is trying to use the mouse wheel to scroll the
> org-export-dispatch window. org-export-dispatch is using the built-in
> function read-char-exclusive, which in turn calls read_filtered_event
> with the parameter error_nonascii set to 0. Unlike read-char, which
> will throw an error upon receiving a mouse event, read-char-exclusive
> just keeps retrying, and eventually the echo area will become full of
> mouse event names.

Yes, I've always wondered what the point of that was.  Test case:

M-: (read-char-exclusive "foo: ")
<mouse-1>

After waiting a bit, the echo area will say:

[down.jpg (image/jpeg, inline)]

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

I don't really see the point of that?  Are there any circumstances that
this is useful?

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

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Lars Ingebrigtsen <larsi <at> gnus.org>
Cc: 19718 <at> debbugs.gnu.org, nandryshak <at> gmail.com
Subject: Re: bug#19718: read_filtered_event echos mouse events until character
 is inputted
Date: Tue, 25 Aug 2020 12:58:47 +0300

> From: Lars Ingebrigtsen <larsi <at> gnus.org>
> Date: Tue, 25 Aug 2020 11:54:21 +0200
> Cc: 19718 <at> debbugs.gnu.org
> 
> Yes, I've always wondered what the point of that was.  Test case:
> 
> M-: (read-char-exclusive "foo: ")
> <mouse-1>
> 
> After waiting a bit, the echo area will say:
> 
> I don't really see the point of that?  Are there any circumstances that
> this is useful?

Isn't this the normal Emacs echoing of prefix keys?  IOW, how is this
different from what you get if you type "C-x v" and wait for a bit?

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

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 19718 <at> debbugs.gnu.org, nandryshak <at> gmail.com
Subject: Re: bug#19718: read_filtered_event echos mouse events until
 character is inputted
Date: Tue, 25 Aug 2020 12:13:19 +0200

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

> Isn't this the normal Emacs echoing of prefix keys?  IOW, how is this
> different from what you get if you type "C-x v" and wait for a bit?

It is the normal echoing, but read-char-exclusive ignores non-character
events, so...  why is it echoing them?

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

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Lars Ingebrigtsen <larsi <at> gnus.org>
Cc: 19718 <at> debbugs.gnu.org, nandryshak <at> gmail.com
Subject: Re: bug#19718: read_filtered_event echos mouse events until
 character is inputted
Date: Tue, 25 Aug 2020 13:38:17 +0300

> From: Lars Ingebrigtsen <larsi <at> gnus.org>
> Cc: nandryshak <at> gmail.com,  19718 <at> debbugs.gnu.org
> Date: Tue, 25 Aug 2020 12:13:19 +0200
> 
> Eli Zaretskii <eliz <at> gnu.org> writes:
> 
> > Isn't this the normal Emacs echoing of prefix keys?  IOW, how is this
> > different from what you get if you type "C-x v" and wait for a bit?
> 
> It is the normal echoing, but read-char-exclusive ignores non-character
> events, so...  why is it echoing them?

Because the echoing happens on a much lower level?

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

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 19718 <at> debbugs.gnu.org, nandryshak <at> gmail.com
Subject: Re: bug#19718: read_filtered_event echos mouse events until
 character is inputted
Date: Tue, 25 Aug 2020 12:40:12 +0200

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

>> It is the normal echoing, but read-char-exclusive ignores non-character
>> events, so...  why is it echoing them?
>
> Because the echoing happens on a much lower level?

So it's not on purpose, but just because that function uses lower-level
functions that have this behaviour?

Then perhaps those should be amended to allow inhibiting this echoing?

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

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

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 19718 <at> debbugs.gnu.org, nandryshak <at> gmail.com
Subject: Re: bug#19718: read_filtered_event echos mouse events until
 character is inputted
Date: Mon, 24 Jan 2022 18:19:12 +0100

Lars Ingebrigtsen <larsi <at> gnus.org> writes:

>> Because the echoing happens on a much lower level?
>
> So it's not on purpose, but just because that function uses lower-level
> functions that have this behaviour?
>
> Then perhaps those should be amended to allow inhibiting this echoing?

Yes, `read-event' does the outputting.  I've now fixed this in Emacs 29,
but I was unsure whether to add a new parameter, or extend the meaning
of the echo-keystrokes variable, so I did the latter -- nil (an
undocumented value) will now be even less updating than before.  I think
it kinda makes sense, but could see redoing this with an extra
parameter, too, if this leads to any issues.

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

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

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: 19718 <at> debbugs.gnu.org
Subject: Re: bug#19718: read_filtered_event echos mouse events until
 character is inputted
Date: Thu, 27 Jan 2022 16:21:36 +0100

This broke `C-q-' echoing by the `C-q' command, so it has to be fixed a
different way.  That is, we don't want to echo new events that are
arriving while we're filtering, but we do want to display the events
that happened before we started the loop.

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

Previous Next

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