Eli Zaretskii schrieb am Sa., 26. März 2016 um 19:08 Uhr: > > From: Philipp Stephani > > Date: Sat, 26 Mar 2016 17:31:46 +0000 > > Cc: 23009-done@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.