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

[Max Mikhanosha <max.mikhanosha@protonmail.com>]

On Tuesday, June 1st, 2021 at 1:38 PM, Eli Zaretskii <eliz@gnu.org> wrote:

> > 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?

No there are two separate toggles in terminal programs (metaSendsEscape:false), and in Emacs itself  (set-input-meta-mode t) and (set-input-mode). First one changes how terminals send it, and 2nd one makes Emacs interpret 8th bit as meta key.  Both of these are non-default, for either Xterm or in Emacse

The (set-input-meta-mode META) parameter in emacs can be either NIL, T or something else, you can lookup the docstring yourself.  Default is 0, which sets keyboard->meta_key = 2, and thus does not affect anything.

I just started Emacs with ./emacs -nw --no-init-file in UTF-8 XTerm, did (current-input-mode) which shows (nil nil 0 7), and typed Alt+aoeuid which produces áïåõé as expected, and exactly same as without my patch.

My patch functionality is specifically enabled only when someone customizes their Emacs to set META parameter of (set-input-mode) to T or NIL, but its behavior is exactly the same as in non-UTF-8 mode.  Only thing it does, is make UTF-8 terminals work exactly same as non-UTF-8 terminals, instead of beaing broken