Keys on the numpad not working properly in gnome-terminal

[TimWolla]

Whenever I press +, -, *, / or return on my numpad instead of inserting the proper character two letters appear: Ok, Om, Oj, Oo, OM in the order of the keys above.

Using git bisect revealed that this commit introduced the issue: a66d440

[timwolla@/d/w/c/fish-shell ((a66d440...)|BISECTING)]g bisect bad                                                                                                                                            17:19:43
a66d44054c4aae44c307b10bb10469b4565e5027 is the first bad commit
commit a66d44054c4aae44c307b10bb10469b4565e5027
Author: David Adam <zanchey@ucc.gu.uwa.edu.au>
Date:   Wed Sep 9 17:11:53 2015 +0800

    reader.cpp: send smkx/rmkx when entering/leaving interactive mode

    Closes #2139.

:040000 040000 6776a81232f5cbde2108b74c80ce8314731a35be 4b408bff02ab5e2293efba51eaaebbffc4981cad M  src

The full bisection log is as follows:

[timwolla@/d/w/c/fish-shell ((a66d440...)|BISECTING)]g bisect log                                                                                                                                            17:20:45
git bisect start
# bad: [be70ea7d49af3cf5bb09116bc278d994fd0cd00c] Add completion for Arch's mkinitcpio
git bisect bad be70ea7d49af3cf5bb09116bc278d994fd0cd00c
# good: [e752ac3035e6438303d79845637a4a2eaea4ff02] Further tweak the language about setting PATH in the tutorial
git bisect good e752ac3035e6438303d79845637a4a2eaea4ff02
# good: [33d062cb60a66d9f03dde1e69db37e1cd864f854] pacman completion: Offer "command-options" first
git bisect good 33d062cb60a66d9f03dde1e69db37e1cd864f854
# good: [d6c97a6a1379526bc2c84210efc5f562a61ffb6d] Fix spelling
git bisect good d6c97a6a1379526bc2c84210efc5f562a61ffb6d
# bad: [31d1e04301f9266aa040a78030992fdaa5995e6e] git completion: Don't check $cmd[1]
git bisect bad 31d1e04301f9266aa040a78030992fdaa5995e6e
# good: [787c1304c6026a40f108b67fd8ffa9eb540a4024] Add file completion for git-reset
git bisect good 787c1304c6026a40f108b67fd8ffa9eb540a4024
# good: [bffeb664cc5cabc4196106d50d830aaf029d06e9] Add __fish_sgrep
git bisect good bffeb664cc5cabc4196106d50d830aaf029d06e9
# bad: [40df11b16235664847f8d72f31bef01aff6615e3] Also allow bold, underline and printing colors in linux kernel VTs
git bisect bad 40df11b16235664847f8d72f31bef01aff6615e3
# good: [e9fcbb334eebdc4a581bf72f1c2e403a4e685ff7] rbenv completion: Support ruby-build as plugin
git bisect good e9fcbb334eebdc4a581bf72f1c2e403a4e685ff7
# bad: [a66d44054c4aae44c307b10bb10469b4565e5027] reader.cpp: send smkx/rmkx when entering/leaving interactive mode
git bisect bad a66d44054c4aae44c307b10bb10469b4565e5027
# first bad commit: [a66d44054c4aae44c307b10bb10469b4565e5027] reader.cpp: send smkx/rmkx when entering/leaving interactive mode

[faho]

What terminal are you using and what is $TERM set to? That commit will cause issues if your TERM is actually incorrect (like saying konsole is "xterm"), but that's to be expected.

[TimWolla]

It's a gnome-terminal 3.14.2 and $TERM is xterm:

[timwolla@~]echo $TERM                                                  18:23:00
xterm
[timwolla@~]gnome-terminal --version                                    18:23:03
GNOME Terminal 3.14.2

It's a stock Ubuntu 15.04 setup, basically.

[faho]

try setting $TERM to either "gnome-256color", "gnome-2012", "vte-2014" or "vte-256color".

[TimWolla]

@faho Either I am doing it wrong, or is does not work with any of these. I was using set -g TERM ….

It does not work in xterm with $TERM= xterm either.

[faho]

Try setting it in the terminal configuration, not config.fish.

[TimWolla]

Doing it according to this post: http://askubuntu.com/a/578798/27683 leads to:

fish: Konnte Terminal nicht einrichten (German for: Could not setup terminal)
fish: Check that your terminal type, 'gnome-256color', is supported on this
system
fish: Attempting to use 'ansi' instead

for all the four values you suggested.

[faho]

With Gnome-Terminal 3.16.2 and current git fish I can reproduce this with TERM=xterm-256color, but enabling numpad (i.e. pressing the actual key) makes it work. I don't get the error with different TERM, but it doesn't seem to help much. I'll need to test some more.

[TimWolla]

@faho It might be, because my computer does not have a physical num lock key. I had to jump through some hoops to get it working generally. See this AskUbuntu question by me: http://askubuntu.com/a/637680/27683

[faho]

Okay, I've tested again. TERM doesn't change the numpad stuff (though backspace only works with TERM=gnome-*, which seems like it describes the actual terminal, or by setting the compatibility option). That only happens when numpad is deactivated (which it was when I first launched gnome-terminal).

It seems like gnome-terminal sends weird character sequences for these keys when numpad is disabled, which e.g. konsole doesn't (it always sends the characters "/", "*" and such).

Now, we should probably add these things to our default bindings.

In the meantime, try adding a fish_user_key_bindings function with stuff like bind Oo "commandline -i /" in it.

[max-m]

Hi,
those weird characters are actually escape sequences, have a look at:
https://ttssh2.osdn.jp/manual/en/usage/tips/appkeypad.html
http://vim.wikia.com/wiki/PuTTY_numeric_keypad_mappings

[faho]

Yeah, but the issue is that, as far as I can tell, these particular escape sequences aren't documented anywhere, in particular not in terminfo, which is supposed to be the database for this stuff.

We've had some changes a week or so ago related to the "st" terminal where @zanchey committed a patch to let fish set "application keypad mode" (or the other mode, I forgot - it sends the "smkx" escape) for itself (which affects more than just the numpad, in particular the arrow keys) and remove it for applications (which should then set it again if they want). This is the commit that @TimWolla bisected to.

Now it appears gnome-terminal in this mode starts caring about the X11 (?) keyboard setting (or at least that's what my testing appears to show - I press the numpad toggle and it toggles between sending the right and the wrong thing). It (or VTE) also by default sets TERM=xterm (or xterm-256color in later VTE versions) but then doesn't behave like xterm - by default the sequence for backspace is wrong.

We can of course hardcode these escapes (like we've done for a bunch of others), but this has two downsides:

• If another terminal sends the same escapes for something else while setting the same TERM, we can't detect it (and way too many things set TERM=xterm, and way too many things only deal with TERM=xterm - even emacs only enables 256colors for a hardcoded list of TERM settings)
• If the user wants to bind custom stuff by key, this only works for what is set in terminfo (unless we hardcode the escapes further down in our stack)

[TimWolla]

In the meantime, try adding a fish_user_key_bindings function with stuff like bind Oo "commandline -i /" in it.

For the moment I went with:

function fish_user_key_bindings
    bind \eOk 'commandline -i +'
    bind \eOm 'commandline -i -'
    bind \eOj 'commandline -i \*'
    bind \eOo 'commandline -i /'
    bind \eOM execute
end

Thanks.

[faho]

Is the "\e" necessary? IIRC I tested it with bare "Ok" and it worked.

[TimWolla]

It is. Without the \e it would not let me type “Ok”, but instead replace
it with the binding. And after pressing Shift+O it would wait to see
whether the next character completes a binding or not.

On 19.09.2015 21:47, Fabian Homborg wrote:

Is the "\e" necessary? IIRC I tested it with bare "Ok" and it worked.

---

Reply to this email directly or view it on GitHub:
#2406 (comment)

[zanchey]

That is super annoying. The smkx changes also break PuTTY - which sends a similar but different set of codes! \eOl for +, \eOS for -...

I'm going to back the smkx changes out for now as it's obvious that the implications are wideranging.

[zanchey]

Should be fixed with 9788566.