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:52 PM, Eli Zaretskii <eliz@gnu.org> wrote:

> OK, but then it cannot really be anything but an opt-in behavior. And
> it cannot be hardcoded to depend on UTF-8 being the keyboard encoding,
> because if a user sets the keyboard encoding to be UTF-8 (something
> very popular these days), it doesn't mean the user gives up the
> ability to type Latin characters in the 128 -- 255 range.

I agree, and I don't really insist on my patch making it in, I understand that you're
reluctant to approve something thats in a hairy area of the code thats very few people
are touching. Reason I posted it, so that if other people having same problem as me
can find the patch easily, if someone is configured their Emacs with 8-bit-meta they
likely to have no problems applying the patch and compiling their own.

> Also, you show the results with input-meta-mode nil or t, but the
> default value is neither nil nor t. What is the effect of the patch
> when input-meta-mode is at its default value?

With default neither nil nor t (ie anything else), it sets kepyboard->meta_key to 2, which means 8-bit clean,
and than neither before my patch nor after my patch 8th bit is never looked at or stripped.

META parameter to keyboard->meta_key mapping in C is:
  NIL   => 0
  T     => 1
  other => 2

This can be trivially seen by grepping kepyboard.c for meta_key, all the if statements referencing meta_key
are either if (meta_key==1), and than if (meta_key != 2) for stripping the 8th bit.

Thus with default value of meta_key==2, there is no change to input decoding either before or after my patch