Re: Emacs difficulties in linux console with ncurses-6.3 caused by kcbt=\E^I.

[Alan Mackenzie]

Hello, Thomas,

thanks for the rapid reply.

On Thu, May 05, 2022 at 20:01:02 -0400, Thomas Dickey wrote:
> On Thu, May 05, 2022 at 06:18:00PM +0000, Alan Mackenzie wrote:
> > 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.

> A bug report got me to verify this, and
> shift-tab on the console appeared to send that sequence,
> so I documented it in the terminal description.

There are many different keyboard layouts used on the linux console.  I
can't say at the moment how many of these use ESC-TAB on the
<shift>-<tab> key combination, how many on <alt>-<tab>, and indeed, how
many on both.  There are around 233 maps in /usr/share/keymaps on my system.

> Tracing changes to default keyboard configuration in Linux isn't
> as "simple" as control-sequences, but see below (it's "kbd").

> I don't see any that send \E[Z.  Having the terminal description
> list a key definition that no one uses isn't very useful.

No, but it's harmless.  Why does the linux console have an entry for kcbt
at all?

> (I'll allow for some keyboard differences -- who has a "clear" key? --
> but shift-tab has been used for a long time).

The point is <shift>-<tab> has stolen the key code for <alt>-<tab>.

> Just to check:
>       Debian, Fedora, Mageia, OpenSUSE do this (send \E^I)
>       Arch, Slackware don't do this (I get just ^I)

> I have a few others that I could check, but (CentOS and Scientific Linux)
> those are either obsolete or derived from the ones that I listed.

There will be people (like me) who set up their own keyboard map files,
and these likely have different codes for <tab> together with all the
modifier keys.

It is highly likely that typeing <esc> produces the code 0x19, and typing
<tab> produces 0x09.  It is not clear that the user will necessarily want
the two-key combination to be transated into <backtab>.

Might it be that terminfo has two different categories of information -
that intrinsic to the terminal (like there being 8 colours), and variable
information determined by the keyboard layout?

> I'm aware that there are (down in the 1% range) still other Linux-based
> systems, but generally speaking few/none of those have contributed
> in this area, so I don't have a machine to verify bug reports.

> fwiw, I noticed some comment in the usual source of misinformation
> recently stating that \E[Z originated with Linux in 1995.
> That was incorrect (the terminal database shows this for several
> AT&T entries and an Ann Arbor Ambassador entry - roughly ten
> years earlier).
 
> > 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.)

> Perhaps that original kcbt was changed to allow the \E^I to work
> with Emacs.  If that's the case, then it should be something that
> I can document in the terminal description.

In Emacs typing <esc> followed by an "ascii character" must produce the
Meta-Char.

What I don't see at the moment is why there is a kcbt capability at all.
Is there an application which depends on it, and would not work properly
without kcbt=\E^I?

> All that I have so far is the commit message, which gives no useful
> information regarding the intent of the change:

>       commit 0baa7f071e79bb700b62b1f8507630387cbc4bbb
>       Author: Alexey Gladkov <legion@altlinux.org>
>       Date:   Tue May 8 22:55:07 2007 +0400

>           Apply patchkbd-1.12-Meta-Tab.diff from SUSE
            
>           Convert Shift Tab to Meta_Tab
            
>           Signed-off-by: Alexey Gladkov <legion@altlinux.org>

> and this equally non-informative mailing list thread:

> https://lists.opensuse.org/archives/list/commit@lists.opensuse.org/message/P3DQHCZB7IWQ7F6VZD3LGXHVOIN6OFE6/

> (which for example doesn't mention Emacs).

As you say, it merely records that there has been a change, not why.

> > 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?

> It was a bug report:

> # 2021-09-04
> #     + modify linux3.0 entry to reflect default mapping of shift-tab by
> #       kbd 1.14 (report by Jan Engelhardt) -TD
 
> > Is there perhaps some strategy we could use in Emacs (C code) which would
> > work around this problem with using ugly ad-hoc code?

> I suppose you could tell Emacs to ignore kcbt (termcap kB) for Linux.

Sorry, I mistyped there.  I meant to write "withOUT using ugly ... code".
Eli Zaretskii, the maintainer of Emacs, is against putting in special
handling for the linux console's kcbt.

For example, is there any facility to modify a terminfo entry for a
particular application, or something like that?

> non-Emacs users probably would like to use the key.

> -- 
> Thomas E. Dickey <dickey@invisible-island.net>
> https://invisible-island.net
> ftp://ftp.invisible-island.net

-- 
Alan Mackenzie (Nuremberg, Germany).