GNU bug report logs - #61022
28.2.50; Mouse tracking of high coordinates not working in rxvt-unicode

Previous Next

Full log

View this message in rfc822 format

From: Eli Zaretskii <eliz <at> gnu.org>
To: Jared Finder <jared <at> finder.org>
Cc: git <at> vladimir.panteleev.md, 61022 <at> debbugs.gnu.org
Subject: bug#61022: 28.2.50; Mouse tracking of high coordinates not working in rxvt-unicode
Date: Tue, 24 Jan 2023 14:24:42 +0200

> Date: Mon, 23 Jan 2023 22:56:09 -0800
> From: Jared Finder <jared <at> finder.org>
> Cc: git <at> vladimir.panteleev.md, 61022 <at> debbugs.gnu.org
> 
> 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.)

Yes, that's how we decode keyboard input using keyboard-coding-system.

> 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.

OK, but shouldn't we also use INHERIT-INPUT-METHOD = t in the call to
read-char only when xterm-mouse-utf-8 option is set?  Otherwise, we
rely on read-char to not perform any conversions, but why rely on that
if we already know we don't want any conversions in that case?  Using
nil when xterm-mouse-utf-8 is unset sounds like a more future-proof
change, no?

Thanks.

Previous Next

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