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

[Eli Zaretskii <eliz@gnu.org>]

> Date: Tue, 01 Jun 2021 17:28:59 +0000
> From: Max Mikhanosha <max.mikhanosha@protonmail.com>
> Cc: emacs-devel@gnu.org
> 
> > If these terminal emulators send M-x as 248 decimal, then how do they
> > send the Latin character ø, whose codepoint is 248 decimal?
> 
> Exactly the same 0xc3,0xb8. Its point of the encode meta-key in the 8th bit mechanics, that you give up ability to type upper half of ASCII table (128-255) instead using them to indicate meta key.  Its a life-safer for those of us using vi, (on in Emacs case evil), otherwise sending meta keys as Esc <key> really interferes with vi mode where Esc key is super-special..  You can still insert these characters by doing quoted-insert, ie C-v M-x and it will insert ø

I see your point, but I don't think we can then accept this patch as
is.  The patch in effect _forces_ everyone to give up on being able to
type 8-bit Latin characters as soon as they configure keyboard
encoding to be UTF-8, right?  Or am I missing something?

> I also typed some stuff in Russian and nothing seem to be broke in UTF8 in general.    If there is a concern that this patch can break something, maybe one way forward is to rework it to add another meaning to meta mode flag, like (set-input-meta-mode 'utf8), which would trigger what my patch is doing.  But current behavior, where meta_key is checked before utf-8 decoding is obviously a bug, as it produces garbage input by treating utf-8 encoding itself as having meta modifiers.

If something like this is accepted, it must be an optional feature.
And I'm not yet sure we want it even then, it sounds like a kludge to
work around broken terminal emulator configuration and cater to other
editors.