From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Alan Mackenzie Newsgroups: gmane.emacs.devel,gmane.comp.lib.ncurses.bugs Subject: Emacs difficulties in linux console with ncurses-6.3 caused by kcbt=\E^I. Date: Thu, 5 May 2022 18:18:00 +0000 Message-ID: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="39534"; mail-complaints-to="usenet@ciao.gmane.io" Cc: emacs-devel@gnu.org To: bug-ncurses@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Thu May 05 20:39:44 2022 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 1nmgO8-000A7U-5N for ged-emacs-devel@m.gmane-mx.org; Thu, 05 May 2022 20:39:44 +0200 Original-Received: from localhost ([::1]:33974 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1nmgO7-0006OO-28 for ged-emacs-devel@m.gmane-mx.org; Thu, 05 May 2022 14:39:43 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:38654) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1nmg3B-0001HB-Se for emacs-devel@gnu.org; Thu, 05 May 2022 14:18:09 -0400 Original-Received: from colin.muc.de ([193.149.48.1]:45601 helo=mail.muc.de) by eggs.gnu.org with smtp (Exim 4.90_1) (envelope-from ) id 1nmg39-00063a-Rr for emacs-devel@gnu.org; Thu, 05 May 2022 14:18:05 -0400 Original-Received: (qmail 26395 invoked by uid 3782); 5 May 2022 18:18:01 -0000 Original-Received: from acm.muc.de (p4fe15ab6.dip0.t-ipconnect.de [79.225.90.182]) (using STARTTLS) by colin.muc.de (tmda-ofmipd) with ESMTP; Thu, 05 May 2022 20:18:01 +0200 Original-Received: (qmail 12854 invoked by uid 1000); 5 May 2022 18:18:00 -0000 Content-Disposition: inline X-Submission-Agent: TMDA/1.3.x (Ph3nix) X-Primary-Address: acm@muc.de Received-SPF: pass client-ip=193.149.48.1; envelope-from=acm@muc.de; helo=mail.muc.de X-Spam_score_int: -18 X-Spam_score: -1.9 X-Spam_bar: - X-Spam_report: (-1.9 / 5.0 requ) BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.29 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:289262 gmane.comp.lib.ncurses.bugs:8540 Archived-At: Hello, ncurses! I'm writing as a member of the Emacs development team. In the recent change from ncurses-6.2 to ncurses-6.3, the following change was make in the linux console terminfo: --- Infocmp-linux-6.2 2022-05-04 20:16:01.609557894 +0000 +++ infocmp-linux-6.3 2022-05-04 20:09:02.046581014 +0000 @@ -14,7 +14,7 @@ home=\E[H, hpa=\E[%i%p1%dG, ht=^I, hts=\EH, ich=\E[%p1%d@, ich1=\E[@, il=\E[%p1%dL, il1=\E[L, ind=\n, initc=\E]P%p1%x%p2%{255}%*%{1000}%/%02x%p3%{255}%*%{1000}%/%02x%p4%{255}%*%{1000}%/%02x, - kb2=\E[G, kbs=^?, kcbt=\E[Z, kcub1=\E[D, kcud1=\E[B, + kb2=\E[G, kbs=^?, kcbt=\E^I, kcub1=\E[D, kcud1=\E[B, kcuf1=\E[C, kcuu1=\E[A, kdch1=\E[3~, kend=\E[4~, kf1=\E[[A, kf10=\E[21~, kf11=\E[23~, kf12=\E[24~, kf13=\E[25~, kf14=\E[26~, kf15=\E[28~, kf16=\E[29~, kf17=\E[31~, We now have kcbt=\E^I. In Emacs on the Linux console, our use of terminfo now has the effect of replacing the M-tab keysequence with backtab. This make several important key-bindings unusable. (The backtab binding is also used, but is perhaps a little less important.) Also, this would seem to be a difficult problem for a normal user to diagnose, and difficult also to fix. May I ask why this change was made to the linux terminal? Is there any possibiliy it might be reverted? Is there perhaps some strategy we could use in Emacs (C code) which would work around this problem with using ugly ad-hoc code? Thanks in advance! -- Alan Mackenzie (Nuremberg, Germany).