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





reply via email to

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