Re: What's happened to M-<tab> `completion-at-point'?

[Alan Mackenzie <acm@muc.de>]

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).