[Top][All Lists]

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

Re: Bugfix for utf-8 XTerm/MinTTY and (set-input-meta-mode t)

From: Max Mikhanosha
Subject: Re: Bugfix for utf-8 XTerm/MinTTY and (set-input-meta-mode t)
Date: Wed, 02 Jun 2021 10:21:26 +0000

On Tuesday, June 1st, 2021 at 4:06 PM, Stefan Monnier 
<monnier@iro.umontreal.ca> wrote:

> > Both XTerm and MinTTY, when configured to send meta modifier as 8th
> > bit while in utf-8 mode, will first add 8th bit, and then encode
> > resulting character with utf-8. For example Meta-X is encoded
> > as ?x+128 = #248 codepoint, encoded as 0xc3,0xb8
> How did they end up with that weird design?

It seems to be logical extension to preserve backward compatibility as much
as possible. I mean since without UTF-8, in meta-as-8th-bit mode, Meta-x 
generates #248,
just having terminal in UTF-8 mode should not change that. And in UTF8, starting
sequences that have 8th bit set indicate start of the encoding, so sending 
as is would be confused for UTF8 sequence by the receiver. Obvious solution 
would be
to just UTF-8 encode the output that non-utf-8 terminal would be sending.

> I mean they could have made meta toggle the 24th bit, for example, so it
> doesn't collide with other existing characters.

There is XTerm solution for this, called modifyOtherKey resource with new enum, 
which can be set
so that any modifiers even on ordinary keys like M-x would generate properly 
ESC[ sequences describing the modifiers. I agree that in perfect world we would 
have come out
with some binary bitmask solution, rather than current thing where terminal can 
send you 20 byte
sequence for Ctrl-Alt-Shift-PageDown, but it is what it is.

> This design is quite weird since it breaks all the latin-1 chars of
> unicode plus all the uses of meta with non-ASCII chars.
> How do they encode M-λ ?
> Is it also sent as the same byte-sequence as `?λ + 128 = ?л` ?

Unfortunately yes, at least mintty in meta-as-8th bit mode (which is my 
terminal on cygwin) just
dumbly shoves 8th bit into even wide characters (like when I press Alt+letter 
in a cyrillic layout), but
my patch does not change that.  TBH Xterm maybe smarter, and just generates 
English M-x when you press
M-x when on a different keyboard layout, or you can probably make it behave 
like this with some xkb
config magic. Proper way to support multi-modifier key sequences is by  using 
modifyOtherKeys:2 but it would
need to have wider adoption than just xterm, hopefully it will percolate to 
other terminals just as
xterm-direct truecolor mode.

For now i'm pretty happy with meta as 8th bit mode, as it allows me to use 
stuff like M-C-v that is sent
as a single char (or 2 in utf8 mode), and with a bit of magic M-S-v and such 
work too, so all my keybindings
are exactly the same regardless if I'm in a terminal or GUI frame.

reply via email to

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