GNU bug report logs - #23009
25.0.92; xterm-mouse-mode should not assume UTF-8 coordinates

Previous Next

Full log

View this message in rfc822 format

From: Philipp Stephani <p.stephani2 <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 23009 <at> debbugs.gnu.org
Subject: bug#23009: 25.0.92; xterm-mouse-mode should not assume UTF-8 coordinates
Date: Sat, 26 Mar 2016 22:26:17 +0000

[Message part 1 (text/plain, inline)]

Eli Zaretskii <eliz <at> gnu.org> schrieb am Sa., 26. März 2016 um 19:08 Uhr:

> > From: Philipp Stephani <p.stephani2 <at> gmail.com>
> > Date: Sat, 26 Mar 2016 17:31:46 +0000
> > Cc: 23009-done <at> debbugs.gnu.org
> >
> > We still might consider solving the flicker problem for "no-conversion".
> Honestly I don't understand the
> > behavior of the meta mode at all: it seems that for the purpose of
> read-char the meta-mode is completely
> > ignored? If so, would it make sense to use
> set-keyboard-coding-system-internal, which doesn't appear to set
> > the meta-mode?
>
> Hmm... what does current-input-mode return on HTerm in "emacs -Q"?


(t nil 0 7)


>   I
> expect to see a non-nil, non-t value in the 3rd element of its return
> value.  If that's so, then testing that value for identity with the
> one we want to pass to set-input-meta-mode, and avoiding the latter
> call if the mode is already what we want, might avoid the flickering.
>
>
Yes, that's already the case (set-input-meta-mode doesn't reinitialize the
terminal if the meta mode doesn't change), and it's why I use latin-1
instead of no-conversion. With latin-1, a single mouse click results in 8
invocations of (set-input-meta-mode 8) (two mouse events with two
coordinates each, and a set and reset per coordinate). With no-conversion,
the same click results in four sequences of (set-input-meta-mode t)
(set-input-meta-mode
8), which causes the flicker.

[Message part 2 (text/html, inline)]

Previous Next

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