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

[Eli Zaretskii <eliz@gnu.org>]

> Date: Tue, 24 Jan 2023 21:09:03 -0800
> From: Jared Finder <jared@finder.org>
> Cc: git@vladimir.panteleev.md, 61022@debbugs.gnu.org
> 
> On 2023-01-24 4:24 am, Eli Zaretskii wrote:
> >> -          (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?
> 
> I think that's not just future-proof, it's more correct.

Thanks.  So I've installed such a change on the emacs-29 branch, and
I'm closing this bug.