emacs-devel
[Top][All Lists]
Advanced

[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: Tue, 01 Jun 2021 18:35:43 +0000

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.



reply via email to

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