Eli Zaretskii <eliz@gnu.org> schrieb am Di., 15. März 2016 um 18:57 Uhr:

> > From: Philipp Stephani <p.stephani2@gmail.com>
> > Date: Mon, 14 Mar 2016 23:03:21 +0000
> > Cc: 23009@debbugs.gnu.org
> >
> > Added a patch. I've had to use latin-1 instead of no-conversion to
> prevent resetting the meta mode.
>
> Not sure I understand the problem you had with no-conversion.  Can you
> elaborate?
>
> > --- a/lisp/international/mule.el
> > +++ b/lisp/international/mule.el
> > @@ -1484,6 +1484,9 @@ set-keyboard-coding-system
> >    (set-keyboard-coding-system-internal coding-system terminal)
> >    (setq keyboard-coding-system coding-system))
> >
> > +(gv-define-setter keyboard-coding-system (coding-system &optional
> terminal)
> > +  `(set-keyboard-coding-system ,coding-system ,terminal))
>
> I don't think you can do that: mule.el is preloaded, while gv.el
> isn't.
>
> It isn't a catastrophe to temporarily switch keyboard encoding "the
> dull way".
>

OK, done.


>
> > +               ;; Use Latin-1 instead of no-conversion to avoid
> > +               ;; flicker due to `set-keyboard-coding-system' changing
> > +               ;; the meta mode.
>
> Ah, so that's the problem...  Did you try raw-text instead?
>
>
Same issue, with both raw-text and no-conversion the
set-keyboard-coding-system function switches the meta mode between t and
nil, leading to flicker.
I guess if the meta mode was nil initially, it would flicker with latin-1.
I'm quite puzzled about this behavior and the meta mode in general now. It
seems that for this purpose (reading a single byte from the terminal) both
nil (ignore top bit) and t (treat top bit as meta) seem wrong, but both
lead to the correct result (i.e. the byte is returned as-is, without
interpretation of the top bit).
Ideally there were a function to read a single byte, ignoring the meta mode
and all conversions.


> And anyway, doesn't latin-1 give you trouble for bytes in the 128..159
> range?
>
>
It works at least in HTerm without flicker or other issues.