SHIFT-TAB not working in Windows-SSH-shell or Debian-tty (sometimes "M-[ ~ is undefined")

SHIFT-TAB not working in Windows-SSH-shell or Debian-tty (sometimes "M-[ ~ is undefined")

[c.buhtz]

X-Post: https://github.com/daviwil/emacs-from-scratch/issues/67

Hello together.

# Introduction

I am quite new to emacs and building my init.el based the "Emacs from
Scratch" (by System Crafter) videos. In org-mode I experience some wired
behavior of the SHIFT-TAB key when (un)folding headings in an
.org file.

# Problem

In some cases SHIFT-TAB creates a M-[ ~ is undefined message or simply
does not work without an error message.

# System

Debian 11
GNU Emacs 27.1 (build 1, x86_64-pc-linux-gnu, GTK+ Version 3.24.24,
cairo version 1.16.0) of 2021-03-28, modified by Debian
Copyright (C) 2020 Free Software Foundation, Inc.

# Minimal init.el

This can be used for reproduction.

;; === Package setup ===
(require 'package)
(setq package-archives '(("melpa" . "https://melpa.org/packages/")
			 ("org" . "https://orgmode.org/elpa/")
			 ("elpa" . "https://elpa.gnu.org/packages/")))
(package-initialize)

;; === use-package ==
;; use-package to simplify the config file
(unless (package-installed-p 'use-package)
  (package-refresh-contents)
  (package-install 'use-package))

(require 'use-package)
(setq use-package-always-ensure 't)

(use-package org)

# Description of the behavior in multiple cases

## Windows SSH-terminal

Form a Windows 10 client and its usual command prompt (not PowerShell,
not Terminal.app) I log into my machine via SSH and (of course) use
emacs in none-gui mode then. TAB works. But SHIFT-TAB produce the M-[ ~
is undefined error.

## A tty terminal (Debian 11)

Here TAB works. But S-TAB does not. The latter does not produce any
error message. There is simply no reaction on that button.

## Cases in where it is NOT reproducable

 - Gui mode in XFCE session on Debian 11
 - Terminal emulator (terminator) in a XFCE session on Debian 11
 - SSH terminal from Debian 11

## Sidenotes

There is a stackoverflow QA for this:
https://stackoverflow.com/q/3518846 The solution there does not work
for me (Emacs from Debian 11).

This problem is totally out of my scope of understanding.

Thanks in advance

Re: SHIFT-TAB not working in Windows-SSH-shell or Debian-tty (sometimes "M-[ ~ is undefined")

[Tim Cross]

<c.buhtz@posteo.jp> writes:

> X-Post: https://github.com/daviwil/emacs-from-scratch/issues/67
>
> Hello together.
>
> # Introduction
>
> I am quite new to emacs and building my init.el based the "Emacs from
> Scratch" (by System Crafter) videos. In org-mode I experience some wired
> behavior of the SHIFT-TAB key when (un)folding headings in an
> .org file.
>
> # Problem
>
> In some cases SHIFT-TAB creates a M-[ ~ is undefined message or simply
> does not work without an error message.
>
> # System
>
> Debian 11
> GNU Emacs 27.1 (build 1, x86_64-pc-linux-gnu, GTK+ Version 3.24.24,
> cairo version 1.16.0) of 2021-03-28, modified by Debian
> Copyright (C) 2020 Free Software Foundation, Inc.
>
> # Minimal init.el
>
> This can be used for reproduction.
>
> ;; === Package setup ===
> (require 'package)
> (setq package-archives '(("melpa" . "https://melpa.org/packages/")
> 			 ("org" . "https://orgmode.org/elpa/")
> 			 ("elpa" . "https://elpa.gnu.org/packages/")))
> (package-initialize)
>
> ;; === use-package ==
> ;; use-package to simplify the config file
> (unless (package-installed-p 'use-package)
>   (package-refresh-contents)
>   (package-install 'use-package))
>
> (require 'use-package)
> (setq use-package-always-ensure 't)
>
> (use-package org)
>
> # Description of the behavior in multiple cases
>
> ## Windows SSH-terminal
>
> Form a Windows 10 client and its usual command prompt (not PowerShell,
> not Terminal.app) I log into my machine via SSH and (of course) use
> emacs in none-gui mode then. TAB works. But SHIFT-TAB produce the M-[ ~
> is undefined error.
>
> ## A tty terminal (Debian 11)
>
> Here TAB works. But S-TAB does not. The latter does not produce any
> error message. There is simply no reaction on that button.
>
> ## Cases in where it is NOT reproducable
>
>  - Gui mode in XFCE session on Debian 11
>  - Terminal emulator (terminator) in a XFCE session on Debian 11
>  - SSH terminal from Debian 11
>
> ## Sidenotes
>
> There is a stackoverflow QA for this:
> https://stackoverflow.com/q/3518846 The solution there does not work
> for me (Emacs from Debian 11).
>
> This problem is totally out of my scope of understanding.
>

I don't think this is an org problem. Rather, I think your probably
running into two different problems which have the same symptom.

Problem 1; Linux Console

The linux console is not the same as a terminal emulator. There are a
number of modifier combinations which are not recognised under the linux
console unless you configure them using the loadkeys command to install
a keymap file (there is also a dumpkeys command to dump out the current
mapping). A full explanation of what to do is beyond a simple mail list
reply, but I would suggest installing the console-data package, which
includes some common keymaps and reading about loadkeys. You will need
to configure your Linux system to load a console keymap on boot to have
key combinations like shift+tab work.

Problem 2: ssh/putty

I'm not a windows user and have never used putty, so this is a bit of a
shot in the dark, but might provide the pointers that will help you find
a solution. When it comes to input issues when using ssh, there are
typically two causes -

1. The host OS running the ssh client (i.e. putty), is stealing the key
combination before it is passed to the underlying program. If your GUI
uses the same key combination to do something (like switch
applications), the key press will not be passed to the underlying
program being run. I doubt this is your issue as I suspect it would be
obvious (i.e. windows would pop up a dialogue to switch applications).

2. The underlying ssh protocol is filtering out the key combination or
re-mapping it to a different combination which is not recognised by the
remote program. This is most likely the issue in your case. The first
thing I would do is have a look at the putty configuration and see if
there are options to enable passing shift, altc, ctl combinations over
ssh. It would also be worthwhile checking to see what the TERM variable
is set to on the remote system when you ssh in as this can also affect
what key combinations are recognised. Part of the problem here is that
programs like putty 'reserve' some 'escape' keys (keys which can be
entered that will be directed to putty rather than the underlying ssh
channel to allow you to break out of the ssh session). 

Note that if your using Windows 10, it includes openSSH as a CLI. You
don't need putty anymore. I would try using the CLI ssh command and see
if that works any better. This might at least let you know if the issue
is a putty issue or an underlying ssh issue - again helping to identify
at what layer you need to focus to fix the issue.

Getting all of this to work can be complicated. This is primarily
because there are often multiple layers involved and getting the right
settings may involve tweaks in multiple layers. It can be frustrating,
but unfortunately, this is what happens when your working across
different platforms and using interfaces designed in different eras. It
took many years before keyboards became standardised. As Emacs
was originally developed under a Unix system, it has some unusual
terminology for keys (Alt, Meta, Hyper, Super), what can seem like
inconsistencies (backspace v delete) and limitations on key combinations
(original ASCII 8 bits limits number of keys which can be represented
with a single key press). This also makes it nearly impossible to set a
default which works across the board for everyone. 

finally, I would be very wary about stack overflow 'solutions'. There
is a lot of outdated and incorrect information on SO. If you try a
solution suggested there and it doesn't work, be very careful to ensure
you undo the changes before trying something else. It is way too easy to
spiral into disaster otherwise. Highly recommend you don't attempt a
suggested solution if you don't understand how it works. Use it as a
resource, but be critical and consider it as just a guide rather than a
cut and paste solution. I've seen way too many people dig themselves
into a deeper hole with SO.