GNU bug report logs -
#61022
28.2.50; Mouse tracking of high coordinates not working in rxvt-unicode
Previous Next
Reported by: git <at> vladimir.panteleev.md
Date: Mon, 23 Jan 2023 05:53:02 UTC
Severity: normal
Found in version 28.2.50
Done: Eli Zaretskii <eliz <at> gnu.org>
Bug is archived. No further changes may be made.
Full log
View this message in rfc822 format
On 2023-01-23 5:15 am, Eli Zaretskii wrote:
>> From: git <at> vladimir.panteleev.md
>> Date: Sun, 22 Jan 2023 19:36:50 +0000
>>
>> For some reason, xt-mouse with xterm-mouse-utf-8 on isn't working for
>> me
>> under rxvt-unicode. I assume it worked at some point, but it's not
>> working now.
>>
...
>> Reproducer:
>>
>> - Run urxvt
>> - In it, run emacs -Q -nw
>> - M-: (require 'xt-mouse)
>> - M-: (setq xterm-mouse-utf-8 t)
>> - M-x xterm-mouse-mode
>> - Make sure the window is wider than 96 lines or columns
>> - Move the mouse around past the 96th line or column
>>
>> Hope this helps.
>
> Jared, any comments?
>
> Thanks.
The change mostly works as inherit-input-method also causes UTF-8
decoding to happen deep in read_char at the C level. (Is this
intentional? I assume so because read-char just reads single bytes
normally.) However, I think the following change is more appropriate:
- (read-char nil nil 0.1))
+ ;; Read a character with input method conversion enabled
+ ;; but no conversion to force read-char to decode UTF-8
+ ;; byte sequences.
+ (let ((input-method-function nil))
+ (read-char nil t 0.1)))
This way we don't apply an actual input method conversion to characters.
For example, without this additional change, if the 'british input
method was active, the # ==> £ conversion would
happen, causing mouse events with X=2 to instead have X=131.
I verified this works for me locally.
-- MJF
This bug report was last modified 2 years and 169 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.