From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Re: Bugfix for utf-8 XTerm/MinTTY and (set-input-meta-mode t) Date: Tue, 01 Jun 2021 20:38:00 +0300 Message-ID: <83fsy1zds7.fsf@gnu.org> References: <83k0ndzfxr.fsf@gnu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="35125"; mail-complaints-to="usenet@ciao.gmane.io" Cc: emacs-devel@gnu.org To: Max Mikhanosha Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Tue Jun 01 19:39:02 2021 Return-path: Envelope-to: ged-emacs-devel@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1lo8M2-0008s5-5J for ged-emacs-devel@m.gmane-mx.org; Tue, 01 Jun 2021 19:39:02 +0200 Original-Received: from localhost ([::1]:51632 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1lo8M1-0007OV-5b for ged-emacs-devel@m.gmane-mx.org; Tue, 01 Jun 2021 13:39:01 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:35426) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1lo8LI-0006Ls-5o for emacs-devel@gnu.org; Tue, 01 Jun 2021 13:38:16 -0400 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]:39074) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1lo8LH-0000R5-PX; Tue, 01 Jun 2021 13:38:15 -0400 Original-Received: from 84.94.185.95.cable.012.net.il ([84.94.185.95]:3272 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1lo8LH-0007fr-Ax; Tue, 01 Jun 2021 13:38:15 -0400 In-Reply-To: (message from Max Mikhanosha on Tue, 01 Jun 2021 17:28:59 +0000) X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.io gmane.emacs.devel:270229 Archived-At: > Date: Tue, 01 Jun 2021 17:28:59 +0000 > From: Max Mikhanosha > 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 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? > I also typed some stuff in Russian and nothing seem to be broke in UTF8 in general. If there is a concern that this patch can break something, maybe one way forward is to rework it to add another meaning to meta mode flag, like (set-input-meta-mode 'utf8), which would trigger what my patch is doing. But current behavior, where meta_key is checked before utf-8 decoding is obviously a bug, as it produces garbage input by treating utf-8 encoding itself as having meta modifiers. If something like this is accepted, it must be an optional feature. And I'm not yet sure we want it even then, it sounds like a kludge to work around broken terminal emulator configuration and cater to other editors.