bug#19718: read_filtered_event echos mouse events until character is inputted

bug#19718: read_filtered_event echos mouse events until character is inputted

[Nick Andryshak]

[-- Attachment #1: Type: text/plain, Size: 1034 bytes --]

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

[-- Attachment #2: Type: text/html, Size: 1573 bytes --]

bug#19718: read_filtered_event echos mouse events until character is inputted

[Noam Postavsky]

severity 19718 minor
quit

Nick Andryshak <nandryshak@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.

bug#19718: read_filtered_event echos mouse events until character is inputted

[Lars Ingebrigtsen]

[-- Attachment #1: Type: text/plain, Size: 773 bytes --]

Nick Andryshak <nandryshak@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:


[-- Attachment #2: down.jpg --]
[-- Type: image/jpeg, Size: 8644 bytes --]

[-- Attachment #3: Type: text/plain, Size: 193 bytes --]


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

bug#19718: read_filtered_event echos mouse events until character is inputted

[Eli Zaretskii]

> From: Lars Ingebrigtsen <larsi@gnus.org>
> Date: Tue, 25 Aug 2020 11:54:21 +0200
> Cc: 19718@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?

bug#19718: read_filtered_event echos mouse events until character is inputted

[Lars Ingebrigtsen]

Eli Zaretskii <eliz@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

bug#19718: read_filtered_event echos mouse events until character is inputted

[Eli Zaretskii]

> From: Lars Ingebrigtsen <larsi@gnus.org>
> Cc: nandryshak@gmail.com,  19718@debbugs.gnu.org
> Date: Tue, 25 Aug 2020 12:13:19 +0200
> 
> Eli Zaretskii <eliz@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?

bug#19718: read_filtered_event echos mouse events until character is inputted

[Lars Ingebrigtsen]

Eli Zaretskii <eliz@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

bug#19718: read_filtered_event echos mouse events until character is inputted

[Lars Ingebrigtsen]

Lars Ingebrigtsen <larsi@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

bug#19718: read_filtered_event echos mouse events until character is inputted

[Lars Ingebrigtsen]

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