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