GNU bug report logs -
#29150
26.0.90; Input decoding is sometimes skipped in TTY (xterm-mouse-mode)
Previous Next
Reported by: Alex <agrambot <at> gmail.com>
Date: Sun, 5 Nov 2017 07:43:02 UTC
Severity: normal
Tags: patch
Found in version 26.0.90
Done: Lars Ingebrigtsen <larsi <at> gnus.org>
Bug is archived. No further changes may be made.
Full log
Message #53 received at 29150 <at> debbugs.gnu.org (full text, mbox):
Eli Zaretskii writes:
>> From: Alex <agrambot <at> gmail.com>
>> Cc: Olaf Rogalsky <olaf.rogalsky <at> t-online.de>, 29150 <at> debbugs.gnu.org, Stefan Monnier <monnier <at> IRO.UMontreal.CA>
>> Date: Sun, 12 Nov 2017 02:25:22 -0600
>>
>> > Thanks, I installed that patch on the release branch.
>>
>> Should it use `read-key' instead?
>
> If that does TRT for xt-mouse, I'm okay with doing that. But please
> wait for Olaf to respond, it's his code after all.
Yes, it does TRT. I wasn't aware of read-key and have a better
understanding of what read-key-event is doing. But using (read-key)
instead of (aref (read-event-vector nil) 0) seems to work equally well.
>> Perhaps the patch should be replaced on the master branch with one that
>> uses `read-key' in all cases?
>
> Why the rush?
I personally have no urgent desires.
>> > Btw, it seems like "C-h k" is not really working for complex mouse
>> > clicks even without xterm-mouse-mode. For example, try this:
>> >
>> > C-h k C-mouse-3
>> >
>> > This pops up a menu; select any item from that menu. The expected
>> > result is to get the description of the menu item you selected, but
>> > instead you get the prompt for "following key, mouse click, or menu
>> > item" anew.
>>
>> This worked fine in Emacs 25.2, FWIW.
Hmm interesting. There are quite a few differences between 25.2 and now
in mouse.el.
--
Olaf Rogalsky
Schwörhausgasse 5
89073 Ulm
Germany
This bug report was last modified 4 years and 70 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.