[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:01:27 +0000 |
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
- Bugfix for utf-8 XTerm/MinTTY and (set-input-meta-mode t), Max Mikhanosha, 2021/06/01
- Re: Bugfix for utf-8 XTerm/MinTTY and (set-input-meta-mode t), Max Mikhanosha, 2021/06/01
- Re: Bugfix for utf-8 XTerm/MinTTY and (set-input-meta-mode t), Eli Zaretskii, 2021/06/01
- Re: Bugfix for utf-8 XTerm/MinTTY and (set-input-meta-mode t),
Max Mikhanosha <=
- Re: Bugfix for utf-8 XTerm/MinTTY and (set-input-meta-mode t), Eli Zaretskii, 2021/06/01
- Re: Bugfix for utf-8 XTerm/MinTTY and (set-input-meta-mode t), Max Mikhanosha, 2021/06/01
- Re: Bugfix for utf-8 XTerm/MinTTY and (set-input-meta-mode t), Eli Zaretskii, 2021/06/01
- Re: Bugfix for utf-8 XTerm/MinTTY and (set-input-meta-mode t), Max Mikhanosha, 2021/06/02
- Re: Bugfix for utf-8 XTerm/MinTTY and (set-input-meta-mode t), Andreas Schwab, 2021/06/02
- Re: Bugfix for utf-8 XTerm/MinTTY and (set-input-meta-mode t), Max Mikhanosha, 2021/06/03
- Re: Bugfix for utf-8 XTerm/MinTTY and (set-input-meta-mode t), Eli Zaretskii, 2021/06/05
Re: Bugfix for utf-8 XTerm/MinTTY and (set-input-meta-mode t), Andreas Schwab, 2021/06/01
Re: Bugfix for utf-8 XTerm/MinTTY and (set-input-meta-mode t), Stefan Monnier, 2021/06/01