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 Subject: Re: What's happened to M- `completion-at-point'? Date: Wed, 4 May 2022 21:07:04 +0000 Message-ID: References: <83bkwd4xle.fsf@gnu.org> <83sfpp2qvy.fsf@gnu.org> <83r1592km7.fsf@gnu.org> 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="3191"; mail-complaints-to="usenet@ciao.gmane.io" Cc: Stefan Monnier , Eli Zaretskii , Emacs developers To: Yuri Khan Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Wed May 04 23:12:55 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 1nmMIp-0000bl-PZ for ged-emacs-devel@m.gmane-mx.org; Wed, 04 May 2022 23:12:55 +0200 Original-Received: from localhost ([::1]:53908 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1nmMIo-0007sM-Cv for ged-emacs-devel@m.gmane-mx.org; Wed, 04 May 2022 17:12:54 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:60082) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1nmMDR-0008Vg-KI for emacs-devel@gnu.org; Wed, 04 May 2022 17:07:21 -0400 Original-Received: from colin.muc.de ([193.149.48.1]:47888 helo=mail.muc.de) by eggs.gnu.org with smtp (Exim 4.90_1) (envelope-from ) id 1nmMDP-0007JJ-Vg for emacs-devel@gnu.org; Wed, 04 May 2022 17:07:21 -0400 Original-Received: (qmail 53866 invoked by uid 3782); 4 May 2022 21:07:04 -0000 Original-Received: from acm.muc.de (p4fe15bd7.dip0.t-ipconnect.de [79.225.91.215]) (using STARTTLS) by colin.muc.de (tmda-ofmipd) with ESMTP; Wed, 04 May 2022 23:07:04 +0200 Original-Received: (qmail 1802 invoked by uid 1000); 4 May 2022 21:07:04 -0000 Content-Disposition: inline In-Reply-To: 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=unavailable 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:289213 Archived-At: Hello, Yuri. On Thu, May 05, 2022 at 03:31:24 +0700, Yuri Khan wrote: > On Thu, 5 May 2022 at 03:16, Stefan Monnier wrote: > > AFAIK the `backtab` is usually used for `S-tab` rather than `M-tab`. > > What do you get if you hit the TAB key together with the Shift modifier? > > Does Emacs also receive the ESC TAB byte sequence in that (and then maps > > it back (correctly this time) to `backtab`)? > On my Ubuntu 22.04 with Linux 5.15.0, in tty, both Shift+Tab and > Alt+Tab produce an ESC TAB sequence. So probably the problem on the > ncurses/terminfo side is induced by a problem on the Linux side. I don't think this is actually the case. If you look at the keyboard mapping file in the kernel: /usr/src/linux-5.15.32/drivers/tty/vt/defkeymap.map , the entry for key 15, the tab key, looks like this: ######################################################################### keycode 15 = Tab Tab alt keycode 15 = Meta_Tab ######################################################################### .. I think that is specifying that both TAB and TAB produce just the Tab character, whereas Tab produces Meta_Tab. This is surely correct. Possibly it was wrong in the kernel, and has been fixed sometime before 5.15.32, but I don't think so. Or, more likely, the collection of keyboard maps in /usr/share/keymaps contains lots of erroneous keymaps. Indeed, looking at just one, /usr/share/keymaps/i386/qwerty/uk.map.gz we see this: ######################################################################### keycode 15 = Tab shift keycode 15 = Meta_Tab <=========================== ######################################################################### .. So I would guess the ncurses maintainers felt themselves in an impossible position, and made the workaround they felt would cause the least damage. Emacs on the Linux console is just an unfortunate casualty. Maybe the best thing we can do in Emacs is to remove that entry for "kB" in src/term.c. That would prevent Emacs recognising TAB on all these misconfigured keyboards. I think that is a lesser evil than failing to recognise TAB. > (In my view, every instance where two distinct keys produce the same > code is a problem.) I think you might be exaggerating a little, but I've got a lot of sympathy for that view. -- Alan Mackenzie (Nuremberg, Germany).