Curious event behavior

[alekratz]

I'm fiddling with odd keyboard input combinations, and some of the weird key combinations aren't getting interpreted correctly. I'll break this down by backend (except for BearLibTerminal which I haven't got installed yet).

ncurses and pancurses

• Modifier + direction keys gives a series of separate events, each of them corresponding to a single character for ANSI escape sequence. E.G. shift + left will raise six events:
  • Key(Esc)
  • '['
  • '1'
  • ';'
  • '2'
  • 'C'
• Ctrl + Numpad4 causes a SIGQUIT. I've tried it on two machines, stable vs. nightly, and with TERM=xterm-256color and screen-256color - it happened each time. I'm going to guess that, with numlock on, for some reason, Ctrl-Numpad4 is getting interpreted as Ctrl-\, which (in case you didn't know) sends SIGQUIT to the foreground program (at least in Linux, not sure about the other Unices). Beyond that, Ctrl + Numpad in any other direction has some funky output:

Ctrl + Numpad N	Event
1	Char('1')
2	Unknown([0, 0, 0, 0])
3	Key(Esc)
4	SIGQUIT
5	Unknown([29, 0, 0, 0])
6	Unknown([30, 0, 0, 0])
7	Unknown([31, 0, 0, 0])
8	Key(Backspace)
9	Char('9')

termion

• Ctrl + numpad works as expected (i.e. CtrlKey('1'), etc), except for:

Ctrl + Numpad N	Event
2	Unknown([])
3	Key(Esc) (note that this matches ncurses behavior)
8	Key(Backspace) (note that this matches ncurses behavior)

• Modifier + direction keys gives a single Event::Unknown with a vector of length 6 - presumably the ANSI escape sequence. e.g. shift + left yields Event::Unknown([27, 91, 49, 59, 50, 68]).
• Not key-input related, but trying to select something via the mouse with the termion backend triggers some kind of redraw that makes it impossible to select anything (since termion rendering is so slow).

I'm doing some weird stuff, I know. There will probably be more to come.

[alekratz]

Also, as a suggestion/feature request, would it be possible to separate numpad interactions into their own key event? I get this feeling it won't be possible (at least in (pa)ncurses), because they probably strip that information out before it gets to us.

[gyscos]

Thank you very much for the detailed report!

A few extra informations could help identify what's going on:

• What OS are you running this on?
• What ncurses version is it using?
• What terminal is it running in?
• What is the value of $TERM?

On my machine (Archlinux, ncurses 6.0, gnome-terminal), Ctrl+Numpad1 just sends Char('1') (it doesn't even see the Ctrl modifier). When NumLock is disabled, it sees Ctrl(End) instead. Ctrl+Numpad4 similarly sends Char('4'). On Konsole, I get your results.

As you noticed, Ctrl+4 behaves like Ctrl+\. On Konsole, Ctrl+Numpad4 behaves the same way; and all those end up killing the foreground program (not just in ncurses app, it works on sleep as well). I didn't know it was a standard thing!

As for key modifiers, here they work correctly for ctrl, shift, alt, ctrl+shift and shift+alt (ctrl+alt changes workspace on gnome), both on konsole and gnome-terminal. Receiving the raw escape code (^[1;2C) means that ncurses itself misses it, which is pretty weird.

For most of those, there's little cursive itself can do. This is what ncurses sends, which is often directly what the terminal sends. The main thing to fix would be the ^[1;2C parsing.

EDIT: just tried termion, and indeed it doesn't crash the same way, so I guess it must put the terminal in a slightly different state - I'll see if I find something there.

Regarding the modifiers key on termion, they don't parse it and just return the escape key. There's an issue for that.

As for mouse dragging, yes, it currently re-draws (and re-layout) the entire app on every event, which was fine for key strokes, but not so much for the event spam the mouse generates. I'll see if speeding up the termion backend is enough, or if we really need conditional re-drawing on events... :(

[alekratz]

• OS is Arch Linux
• ncurses 6.0
• Terminal is alacritty
• $TERM for all tests (except where indicated otherwise) is screen-256color

I did not have the chance to test other terminals, but in the future I'll try to do that before submitting something like this.

I didn't know it was a standard thing!

After some quick googling it looks like ctrl-4 for sending SIGQUIT is not exactly "standard" but more of a side effect of the way terminal entry is handled. This link has a pretty good explanation. https://unix.stackexchange.com/questions/226327/what-does-ctrl4-and-ctrl-do-in-bash

For everything else I've mentioned, it's probably an alacritty thing. I forgot I probably should use non-beta software to test other software. Oops.

[gyscos]

Wooow, with export TERM=screen-256color indeed I get the same escapes for the ctrl-arrow keys. Looks like ncurses is deeply confused by the specific term value... Here, running screen apparently uses TERM=screen.xterm-256color, and it seems to work better with ncurses.

[gyscos]

It seems we fail to detect some of these key combinations in rxvt as well. Shift+Left and Shift+Right are detected, but not Shift+Up/Down (those send ^[a/^[b), and not the Ctrl ones (those send ^Oa...^Od).

I'm a bit confused by what ncurses detects; I hoped it would adapt the the current terminfo and work on those multiple terminals.

[alexanderkjall]

Just another datapoint:

I see the same problem with Ctrl + Numpad N on gnome-terminal with the ncurses backend