Ticket #3254 (new defect)

Opened 4 years ago

Last modified 19 months ago

Shift+Fn keys are off by two in ncurses

Reported by: egmont Owned by:
Priority: major Milestone: Future Releases
Component: mc-tty Version: master
Keywords: Cc: mrmazda@…
Blocked By: Blocking:
Branch state: no branch Votes for changeset:

Description

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.

Change History

comment:1 Changed 4 years ago by ossi

deja vu #367?

comment:2 Changed 4 years ago by 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.

comment:3 Changed 4 years ago by mrmazda

  • Cc mrmazda@… added

comment:4 follow-up: ↓ 5 Changed 4 years ago by 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.

Last edited 4 years ago by o.pikozh (previous) (diff)

comment:5 in reply to: ↑ 4 Changed 4 years ago by 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.

comment:6 Changed 19 months ago by andrew_b

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

comment:7 Changed 19 months ago by andrew_b

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

Note: See TracTickets for help on using tickets.