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

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

Ok I'll rework the patch along these lines, and submit again later. Do you have a suggestion or input-meta-mode new enum value? My only idea is 'ENCODED, to mean same as T but that 8th bit will be checked after decoding the input with whatever keyboard coding system is.

‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐

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

> > Date: Tue, 01 Jun 2021 18:01:27 +0000
>
> > From: Max Mikhanosha max.mikhanosha@protonmail.com
> >
> > Cc: emacs-devel@gnu.org
> >
> > 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
>
> But UTF-8 is not the only encoding that uses the 8th bit. So this
>
> must be a separate setting, unrelated to the encoding being UTF-8 or
>
> not. What you want is for Emacs to interpret the 8th bit after
>
> decoding characters and not before it as it does now. So I think a
>
> new non-nil value of input-meta-mode should be introduced to trigger
>
> this behavior, and you should drop the tests of the encoding being
>
> UTF-8, as it's not the only encoding that can be affected.