bug-gnu-emacs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#23009: 25.0.92; xterm-mouse-mode should not assume UTF-8 coordinates


From: Eli Zaretskii
Subject: bug#23009: 25.0.92; xterm-mouse-mode should not assume UTF-8 coordinates
Date: Sat, 02 Apr 2016 12:43:13 +0300

> Date: Sun, 27 Mar 2016 18:21:10 +0300
> From: Eli Zaretskii <address@hidden>
> Cc: address@hidden
> 
> > From: Philipp Stephani <address@hidden>
> > Date: Sat, 26 Mar 2016 22:26:17 +0000
> > Cc: address@hidden
> > 
> >  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.
> 
> Then I guess I'm confused about the reason for (set-input-meta-mode t)
> in the case of no-conversion -- don't we want Emacs to pass the 8th
> bit through without interpreting it?  Perhaps Handa-san could comment
> on this, as I'm otherwise inclined to add raw-text to the list of the
> coding-system types that want a non-nil, non-t value to be passed to
> set-input-meta-mode.

Ping!

Philipp, can you try adding raw-text to that list, and see if the
result works correctly?





reply via email to

[Prev in Thread] Current Thread [Next in Thread]