Eli Zaretskii <eliz@gnu.org> schrieb am Sa., 2. Apr. 2016 um 11:43 Uhr:

> > Date: Sun, 27 Mar 2016 18:21:10 +0300
> > From: Eli Zaretskii <eliz@gnu.org>
> > Cc: 23009@debbugs.gnu.org
> >
> > > From: Philipp Stephani <p.stephani2@gmail.com>
> > > Date: Sat, 26 Mar 2016 22:26:17 +0000
> > > Cc: 23009@debbugs.gnu.org
> > >
> > >  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?
>

Yes, it works (unsurprisingly), I've attached a patch.