Shift+Fn keys are off by two in ncurses

[egmont]

In the slang build, Shift+F1 - Shift+F10 work as expected. (Also, in the editor Shift+F1 can be used instead of F11 to bring up the User menu, and Shift+F2 instead of F12 for Save as.)

In the ncurses build they are off by two, e.g. Shift+F6 wants to delete the file under the cursor.

I see this behavior on Ubuntu Trusty, TERM=xterm-256color, with xterm, gnome-terminal and st (all manually upgraded to their newest version, they emit Shift+F1=\e[1;2P, Shift+F5=\e[15;2~ etc.), konsole (Shift+F1=\eO2P, Shift+F5=\e[15;2~).

The bug does not occur on pterm (putty) which generates Shift+F1=\e[23~, Shift+F5=\e[28~ etc.

[ossi]

deja vu #367?

[egmont]

Indeed, although... 5 years ago you wrote "it works now in both xterm and konsole, but it is consistently failing on the linux console" – on the console it's the kbd package that's broken because half of the keymaps are shifted by 2 compared to the other half. To make it worse, the kernel's builtin table just doesn't match the standard "us" layout shipped by kbd or console-tools or whatever that's called nowadays.

This time it's broken in xterm and other graphical emulators, where it has absolutely no reason to be broken.

[o.pikozh]

I use mc in KUbuntu trusty ("Using the S-Lang library with terminfo database").
In Konsole (xterm-like terminal emulator, TERM=xterm) Shift+Fn keys work fine.
However, on ttyN (linux console, TERM=linux) Shift+Fn keys act as Shift+F(n+2).

This is because Shift+Fn in my distrib produces F(n+12), not F(n+10) as mc expects:

$ dumpkeys -f | egrep 'F1 '
keycode 59 = F1 F13 [...]
string F1 = "\033[[A"

Per my opinion, we should abandon F11/F20 notation (in menus, "Learn keys" dialog, keymap files, etc) and use S-F1..S-F10 strings instead. And, whether S-Fn=F(n+12) or S-Fn=F(n+10) should be not hard-coded; it should but depend on some value (values? term-dependent?) in ini-file (both in ~ and /etc/mc, because in /etc it can be provided by distro maintainer) (S-F1..S-F10 should be still overrideable by "Learn keys", but whether mc expects S-F1 to be F11 or F13 by default should depend on configs).

P.S.: I can provide full 'mc -V', 'dumpkeys -f', 'infocmp linux', 'infocmp xterm', 'showkey -a' in Konsole and 'showkey -a' in VT if needed.

[egmont]

Replying to o.pikozh:

However, on ttyN (linux console, TERM=linux) Shift+Fn keys act as Shift+F(n+2).
This is because Shift+Fn in my distrib produces F(n+12), not F(n+10) as mc expects:

See comment 3.

Until that one is solved (i.e. the kbd/console-tools package ships keymaps that are consistent with each other and with the kernel's default) there's nothing mc could do.

(Anyone willing to work on this?)

Per my opinion, we should abandon F11/F20 notation [...] and use S-F1..S-F10 strings instead.

I totally support this idea (see also #3087), but it doesn't make too much sense to touch this until the underlying issue with ttyN keymaps is fixed.

Note: The original report was about ncurses with graphical terminals, which is a quite different story.

[andrew_b]

Ticket #3807 has been marked as a duplicate of this ticket.

[andrew_b]

Ticket #2885 has been marked as a duplicate of this ticket.