unofficial mirror of emacs-devel@gnu.org 
 help / color / mirror / code / Atom feed
From: Alan Mackenzie <acm@muc.de>
To: Yuri Khan <yuri.v.khan@gmail.com>
Cc: Stefan Monnier <monnier@iro.umontreal.ca>,
	Eli Zaretskii <eliz@gnu.org>,
	Emacs developers <emacs-devel@gnu.org>
Subject: Re: What's happened to M-<tab> `completion-at-point'?
Date: Wed, 4 May 2022 21:07:04 +0000	[thread overview]
Message-ID: <YnLq+AMDPW6UCaOL@ACM> (raw)
In-Reply-To: <CAP_d_8UO9DeL5RV15w7cfN+C0Ba3D_9=Un7fnQ3=upKbRVUFCA@mail.gmail.com>

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 <monnier@iro.umontreal.ca> 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 <shift>TAB produce just
the Tab character, whereas <alt>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 <shift>TAB on all
these misconfigured keyboards.  I think that is a lesser evil than
failing to recognise <meta>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).



  parent reply	other threads:[~2022-05-04 21:07 UTC|newest]

Thread overview: 26+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-05-03 21:06 What's happened to M-<tab> `completion-at-point'? Alan Mackenzie
2022-05-04  6:32 ` Eli Zaretskii
2022-05-04 16:34   ` Alan Mackenzie
2022-05-04 16:40     ` Eli Zaretskii
2022-05-04 18:13       ` Alan Mackenzie
2022-05-04 18:55         ` Eli Zaretskii
2022-05-04 19:10           ` Alan Mackenzie
2022-05-04 19:47             ` Yuri Khan
2022-05-04 20:16               ` Stefan Monnier
2022-05-04 20:31                 ` Yuri Khan
2022-05-04 20:50                   ` Stefan Monnier
2022-05-04 21:07                   ` Alan Mackenzie [this message]
2022-05-05  5:03                     ` tomas
2022-05-05  6:20                     ` Eli Zaretskii
2022-05-05 16:57                       ` Alan Mackenzie
2022-05-05 17:28                         ` Eli Zaretskii
2022-05-06 23:19                           ` Richard Stallman
2022-05-07 11:03                             ` Alan Mackenzie
2022-05-08 23:35                               ` Richard Stallman
2022-05-04 20:35               ` Alan Mackenzie
2022-05-04 19:16           ` Tassilo Horn
2022-05-04 19:39             ` Eli Zaretskii
2022-05-04 19:45               ` Tassilo Horn
2022-05-04 19:57               ` Andreas Schwab
2022-05-04  6:33 ` Lars Ingebrigtsen
2022-05-04 16:26   ` Alan Mackenzie

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.gnu.org/software/emacs/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=YnLq+AMDPW6UCaOL@ACM \
    --to=acm@muc.de \
    --cc=eliz@gnu.org \
    --cc=emacs-devel@gnu.org \
    --cc=monnier@iro.umontreal.ca \
    --cc=yuri.v.khan@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).