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

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

[Alan Mackenzie]

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

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

[Thomas Dickey]

[-- Attachment #1: Type: text/plain, Size: 4117 bytes --]

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.

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

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.

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.

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

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

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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 659 bytes --]

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

[Stefan Monnier]

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

The problem is that both Alt-TAB and Shift-TAB send that same byte
sequence, so claiming that ESC TAB is `backtab` is not really correct.
It may be `backtab` but it may be Meta-TAB as well.

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

Interesting.  So it looks like the intent of the change was to make
Shift-TAB behave as another Meta-TAB, whereas with the ncurses change
the end result is that Shift-TAB was changed to `backtab` (rather than
Meta-TAB) and Meta-TAB was made "impossible" to input.


        Stefan

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

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

[Eli Zaretskii]

> Date: Fri, 6 May 2022 18:49:39 +0000
> Cc: bug-ncurses@gnu.org, emacs-devel@gnu.org
> From: Alan Mackenzie <acm@muc.de>
> 
> > > 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.

I'm not against that, I'm against doing that in term.c for all the
text-mode terminals.  You could, for example, modify input-decode-map
in lisp/term/linux.el, and that would be OK with me, if there's no
better solution for this.  Doing that will cause users of Emacs on the
Linux console to lose Backtab and gain M-TAB instead.  Personally, I'm
not sure which one is more important, but then I don't use the Linux
console.

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

[Alan Mackenzie]

Hello, Eli.

On Fri, May 06, 2022 at 22:14:04 +0300, Eli Zaretskii wrote:
> > Date: Fri, 6 May 2022 18:49:39 +0000
> > Cc: bug-ncurses@gnu.org, emacs-devel@gnu.org
> > From: Alan Mackenzie <acm@muc.de>

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

> I'm not against that, I'm against doing that in term.c for all the
> text-mode terminals.

I misunderstood you, there, sorry.  I'd misunderstood the code, and I
thought (without thinking) that the translation functionality for
terminfo settings would be buried deep in the C code, somewhere.

> You could, for example, modify input-decode-map in lisp/term/linux.el,
> and that would be OK with me, if there's no better solution for this.

That's the bit I missed - that the pertinent translation into 'backtab
is done by the input-decode-map.  So, as you say, all that is needed is
to remove the <esc><tab> binding from that keymap.  I'll take back what
I said about the problem being difficult to fix.

Maybe we can write an entry in PROBLEMS and leave it to the user to fix
in her .emacs.  Or maybe we can put code in lisp/term/linux.el
ourselves.

> Doing that will cause users of Emacs on the Linux console to lose
> Backtab and gain M-TAB instead.  Personally, I'm not sure which one is
> more important, but then I don't use the Linux console.

I don't know how typical I am of Linux console users, but I have my
keymap set up to send a different code for <shift><tab> - namely
"\033[4}\011".  This is according to a scheme developed by Kalle
Niemitalo over twenty years ago, which enables one to add bindings for
any key with any modifier combination.  There are matching bindings in
input-decode-map to interpret these prefixes.

What was so painful was that typing <esc> and <tab> separately failed to
combine into M-tab, and I couldn't see a way of getting around that.

-- 
Alan Mackenzie (Nuremberg, Germany).

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

[Eli Zaretskii]

> Date: Sat, 7 May 2022 10:41:46 +0000
> Cc: dickey@his.com, bug-ncurses@gnu.org, emacs-devel@gnu.org
> From: Alan Mackenzie <acm@muc.de>
> 
> > I'm not against that, I'm against doing that in term.c for all the
> > text-mode terminals.
> 
> I misunderstood you, there, sorry.  I'd misunderstood the code, and I
> thought (without thinking) that the translation functionality for
> terminfo settings would be buried deep in the C code, somewhere.

Some of it is, actually.  But users can countermand at least some of
that code in their customizations.

> > You could, for example, modify input-decode-map in lisp/term/linux.el,
> > and that would be OK with me, if there's no better solution for this.
> 
> That's the bit I missed - that the pertinent translation into 'backtab
> is done by the input-decode-map.  So, as you say, all that is needed is
> to remove the <esc><tab> binding from that keymap.  I'll take back what
> I said about the problem being difficult to fix.
> 
> Maybe we can write an entry in PROBLEMS and leave it to the user to fix
> in her .emacs.  Or maybe we can put code in lisp/term/linux.el
> ourselves.

I'm okay with both alternatives, since I have no opinion on what is
more important to users of Emacs on the Linux console.

> I don't know how typical I am of Linux console users, but I have my
> keymap set up to send a different code for <shift><tab> - namely
> "\033[4}\011".

Perhaps that PROBLEMS entry could suggest that as well, so that users
could have the cake and eat it, too.

Thanks.

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

[Alan Mackenzie]

Hello, Eli.

On Sat, May 07, 2022 at 13:45:44 +0300, Eli Zaretskii wrote:
> > Date: Sat, 7 May 2022 10:41:46 +0000
> > Cc: dickey@his.com, bug-ncurses@gnu.org, emacs-devel@gnu.org
> > From: Alan Mackenzie <acm@muc.de>

> > > I'm not against that, I'm against doing that in term.c for all the
> > > text-mode terminals.

> > I misunderstood you, there, sorry.  I'd misunderstood the code, and I
> > thought (without thinking) that the translation functionality for
> > terminfo settings would be buried deep in the C code, somewhere.

> Some of it is, actually.  But users can countermand at least some of
> that code in their customizations.

Which is most helpful, here.

> > > You could, for example, modify input-decode-map in lisp/term/linux.el,
> > > and that would be OK with me, if there's no better solution for this.

> > That's the bit I missed - that the pertinent translation into 'backtab
> > is done by the input-decode-map.  So, as you say, all that is needed is
> > to remove the <esc><tab> binding from that keymap.  I'll take back what
> > I said about the problem being difficult to fix.

> > Maybe we can write an entry in PROBLEMS and leave it to the user to fix
> > in her .emacs.  Or maybe we can put code in lisp/term/linux.el
> > ourselves.

> I'm okay with both alternatives, since I have no opinion on what is
> more important to users of Emacs on the Linux console.

Having thought about it, I think putting

    (define-key input-decode-map "\e\t" nil)

into lisp/term/linux.el would be the best thing.  It will restore Emacs
on the Linux console to what it was before the recent ncurses release.

> > I don't know how typical I am of Linux console users, but I have my
> > keymap set up to send a different code for <shift><tab> - namely
> > "\033[4}\011".

> Perhaps that PROBLEMS entry could suggest that as well, so that users
> could have the cake and eat it, too.

Here's a first stab at the PROBLEMS entry, under * Runtime problems on
character terminals>:


** The shift tab key combination works as meta tab on a Linux console.

This happens because on your keyboard layout, S-Tab produces the same
keycodes as typing Esc Tab individually.  The best way to solve this
is to modify your keyboard layout to produce different codes, and tell
Emacs what these new codes mean.

The current keyboard layout will probably be a .map.gz file somewhere
under /usr/share/keymaps.  Identify this file, possibly from a system
initialization file such as /etc/conf.d/keymaps.  Run gunzip on it to
decompress it, and amend the entries for keycode 15 to look something
like this:

keycode  15 = Tab
        alt     keycode  15 = Meta_Tab
        shift keycode 15 = F219
string F219 = "\033[4}\011"      # Shift+<tab>

After possibly saving this file under a different name, compress it
again using gzip.  Amend /etc/conf.d/keyamps, etc., if needed.
Further details can be found in the man page for loadkeys.

Then add the following line near the start of your site-start.el or
..emacs or init.el file:

(define-key input-decode-map "\e[4}\t" 'backtab)


> Thanks.

-- 
Alan Mackenzie (Nuremberg, Germany).

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

[Eli Zaretskii]

> Date: Sat, 7 May 2022 14:35:06 +0000
> Cc: dickey@his.com, bug-ncurses@gnu.org, emacs-devel@gnu.org
> From: Alan Mackenzie <acm@muc.de>
> 
> > > Maybe we can write an entry in PROBLEMS and leave it to the user to fix
> > > in her .emacs.  Or maybe we can put code in lisp/term/linux.el
> > > ourselves.
> 
> > I'm okay with both alternatives, since I have no opinion on what is
> > more important to users of Emacs on the Linux console.
> 
> Having thought about it, I think putting
> 
>     (define-key input-decode-map "\e\t" nil)
> 
> into lisp/term/linux.el would be the best thing.  It will restore Emacs
> on the Linux console to what it was before the recent ncurses release.

Fine with me.

> > > I don't know how typical I am of Linux console users, but I have my
> > > keymap set up to send a different code for <shift><tab> - namely
> > > "\033[4}\011".
> 
> > Perhaps that PROBLEMS entry could suggest that as well, so that users
> > could have the cake and eat it, too.
> 
> Here's a first stab at the PROBLEMS entry, under * Runtime problems on
> character terminals>:

Also fine, thanks.  But please capitalize "TAB" and "ESC" in the text,
to make them consistent with our notation elsewhere.

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

[Alan Mackenzie]

Hello, Eli.

On Sat, May 07, 2022 at 18:03:45 +0300, Eli Zaretskii wrote:
> > Date: Sat, 7 May 2022 14:35:06 +0000
> > Cc: dickey@his.com, bug-ncurses@gnu.org, emacs-devel@gnu.org
> > From: Alan Mackenzie <acm@muc.de>

> > > > Maybe we can write an entry in PROBLEMS and leave it to the user to fix
> > > > in her .emacs.  Or maybe we can put code in lisp/term/linux.el
> > > > ourselves.

> > > I'm okay with both alternatives, since I have no opinion on what is
> > > more important to users of Emacs on the Linux console.

> > Having thought about it, I think putting

> >     (define-key input-decode-map "\e\t" nil)

> > into lisp/term/linux.el would be the best thing.  It will restore Emacs
> > on the Linux console to what it was before the recent ncurses release.

> Fine with me.

OK, DONE, it works.  :-)

> > > > I don't know how typical I am of Linux console users, but I have my
> > > > keymap set up to send a different code for <shift><tab> - namely
> > > > "\033[4}\011".

> > > Perhaps that PROBLEMS entry could suggest that as well, so that users
> > > could have the cake and eat it, too.

> > Here's a first stab at the PROBLEMS entry, under * Runtime problems on
> > character terminals>:

> Also fine, thanks.  But please capitalize "TAB" and "ESC" in the text,
> to make them consistent with our notation elsewhere.

One other little thing: I think this problem counts as "major" or "safe",
so the fix should go onto the release branch, shouldn't it, despite the
upcoming release being nn.2?

-- 
Alan Mackenzie (Nuremberg, Germany).

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

[Eli Zaretskii]

> Date: Sat, 7 May 2022 17:37:10 +0000
> Cc: dickey@his.com, bug-ncurses@gnu.org, emacs-devel@gnu.org
> From: Alan Mackenzie <acm@muc.de>
> 
> One other little thing: I think this problem counts as "major" or "safe",
> so the fix should go onto the release branch, shouldn't it, despite the
> upcoming release being nn.2?

Probably.

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

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

I am getting the feeling that Emacs should do nothing special about M-TAB,
and that we should talk with maintainers of free distros about the change
made to the terminfo database.  It looks like we don't know enough
about the pros and cons of the terminfo change to be able to judge it.

Maybe we should talk with the maintainers of free distros about that.

Is it possible for Emacs to notice that the terminfo database includes
that change, and if so, display a notice whenever the Backtab key arrives
as input?  This could tell users (1) how to revert that terminfo change,
(2) a guide to raising the issue with distro maintainers.


-- 
Dr Richard Stallman (https://stallman.org)
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)

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

[Alan Mackenzie]

Hello again, Thomas.

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.

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

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

Just to say that fixing Emacs to work with kcbt=\E^I wasn't actually very
difficult at all, and I've committed a patch to the Emacs repository with
this fix.

I think it's a shame that there has been this confusion between
<shift>TAB and <alt>TAB over the decades.  This has made things difficult
for applications like Emacs, which use both of these.

So my position now is that I no longer have a view on what the best
setting for kcbt in the linux console terminfo entry is.

[ .... ]

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

This is in effect what has been done.

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

Yes.  ;-(

Thank you very much for your time, and the additional background
information, over the last few days.

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

-- 
Alan Mackenzie (Nuremberg, Germany).

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

[Thomas Dickey]

[-- Attachment #1: Type: text/plain, Size: 3118 bytes --]

On Sun, May 08, 2022 at 12:09:53PM +0000, Alan Mackenzie wrote:
> Hello again, Thomas.
> 
> 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.
> 
> > 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.
> > (I'll allow for some keyboard differences -- who has a "clear" key? --
> > but shift-tab has been used for a long time).
> 
> > 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.
> 
> Just to say that fixing Emacs to work with kcbt=\E^I wasn't actually very
> difficult at all, and I've committed a patch to the Emacs repository with
> this fix.
> 
> I think it's a shame that there has been this confusion between
> <shift>TAB and <alt>TAB over the decades.  This has made things difficult
> for applications like Emacs, which use both of these.
> 
> So my position now is that I no longer have a view on what the best
> setting for kcbt in the linux console terminfo entry is.
> 
> [ .... ]
> 
> > I suppose you could tell Emacs to ignore kcbt (termcap kB) for Linux.
> 
> This is in effect what has been done.

sounds good - no better solution came to mind
 
> > non-Emacs users probably would like to use the key.
> 
> Yes.  ;-(
> 
> Thank you very much for your time, and the additional background
> information, over the last few days.

no problem (report bugs)

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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 659 bytes --]