search

skogsbaer / hscurses

ncurses binding for Haskell
http://hackage.haskell.org/package/hscurses
GNU Lesser General Public License v2.1
61 stars 21 forks source link

Keypad no longer sends numbers #8

Closed Mikolaj closed 13 years ago

Mikolaj commented 13 years ago

Ubuntu GNU/Linux on amd64, tested with https://github.com/kosmikus/LambdaHack.

Numerical keypad keys stopped working correctly with Shift in hscurses 1.4.0.0 or 1.4.1.0, namely they no longer produce numbers when pressed together with Shift (as they normally do on command line in xterm and Gnome Terminal and as they did in hscurses under xterm in 1.3.0.2; under Gnome Terminal it never worked, though). This may be related to the fix of issue #4. Interestingly, the keys do work correctly in xterm when I change the NumLock setting, that is they send numbers without Shift (in xterm and Gnome Terminal), and produce arrows, PgUp, Begin, End, Home, etc., with Shift (but not in Gnome Terminal, where they produce random Esc sequences).

skogsbaer commented 13 years ago

There is a test program in directory tests/key-test of the hscurses repo. Using this test program, I could not reproduce your bug. With NumLock activated, the keypad keys produce numbers as expected. With NumLock and Shift activated, the keypad keys produce arrows, PageUp, PageDown, Home, and End as expected. Without NumLock and without Shift, the keypad keys produce arrows, PageUp, PageDown, Home, and End as expected. Without NumLock but with Shift, the keypad keys do indeed produce some strange escape sequences, but what else would you expect?

Mikolaj commented 13 years ago

Thank you for the hint and for the testing (and for taking over, I feared hscurses is forever abandoned). Here are my results (Acer laptop, the same results with the laptop keyboard and with external Apple keyboard, gnome terminal 2.32.1, XTerm(268), newest Ubuntu; the results were similar months ago on different PC machines with different keyboards and X keyboard settings, but this time I tested only with this setup).

With NumLock activated, the keypad keys produce numbers as expected

Confirmed.

With NumLock and Shift activated, the keypad keys produce arrows, PageUp, PageDown, Home, and End as expected.

Not so here. The results with gnome terminal are KeySRight, KeySLeft, KeyUp, KeyDown, and the remaining 4 keys are totally mute. With xterm the results are OK: KeyRight, KeyLeft, KeyUp, KeyDown, PageUp, PageDown, Home, and End.

Without NumLock and without Shift, the keypad keys produce arrows, PageUp, PageDown, Home, and End as expected.

True for xterm, but for gnome terminal, Home and End produce KeyChar '\ESC' and KeyChar '~'. This is the main issue I complain about in #9.

Without NumLock but with Shift, the keypad keys do indeed produce some strange escape sequences

The strange escape sequences confirmed for xterm, for all keys. For gnome terminal, it produces perfect numbers (I guess I was misled in the bug report above, it might have worked for gnome terminal last time I checked as well, so the regression is only for xterm).

but what else would you expect?

I'd expect what vty and gtk do and what gnome-terminal tricks hscurses into doing (on my computer, today, at least) and what 1.3.0.2 did under xterm, that is, correct numbers.

skogsbaer commented 13 years ago

Thank you for the hint and for the testing (and for taking over, I feared hscurses is forever abandoned). Here are my results (Acer laptop, the same results with the laptop keyboard and with external Apple keyboard, gnome terminal 2.32.1, XTerm(268), newest Ubuntu; the results were similar months ago on different PC machines with different keyboards and X keyboard settings, but this time I tested only with this setup).

With NumLock activated, the keypad keys produce numbers as expected

Confirmed.

good.

With NumLock and Shift activated, the keypad keys produce arrows, PageUp, PageDown, Home, and End as expected.

Not so here. The results with gnome terminal are KeySRight, KeySLeft, KeyUp, KeyDown, and the remaining 4 keys are totally mute. With xterm the results are OK: KeyRight, KeyLeft, KeyUp, KeyDown, PageUp, PageDown, Home, and End.

I think that's also ok, at least concerning hscurses. KeySRight and KeySLeft are documented (in ncurses.h) as "shifted right-arrow key" and "shifted left-arrow key". There are, however, no shifted version of Up and Down defined in ncurses.h

Without NumLock and without Shift, the keypad keys produce arrows, PageUp, PageDown, Home, and End as expected.

True for xterm, but for gnome terminal, Home and End produce KeyChar '\ESC' and KeyChar '~'. This is the main issue I complain about in #9.

I checked this with another curses-based C application (mutt). Here, the keypad keys without numlock produce the expected results with xterm, but with gnome-terminal some keys are not working (e.g. "7" does not produce "Home" and "1" does not produce "End" as under xterm). Thus, I suspect that hscurses is not the problem but curses itself or the terminal configuration or whatever.

Without NumLock but with Shift, the keypad keys do indeed produce some strange escape sequences

The strange escape sequences confirmed for xterm, for all keys. For gnome terminal, it produces perfect numbers (I guess I was misled in the bug report above, it might have worked for gnome terminal last time I checked as well, so the regression is only for xterm).

but what else would you expect?

I'd expect what vty and gtk do and what gnome-terminal tricks hscurses into doing (on my computer, today, at least) and what 1.3.0.2 did under xterm, that is, correct numbers.

This seems also to be a curses issue. Keep in mind that hscurses is only a wrapper around curses. The 'decodeKey' function in Curses.hsc doesn't do any magic on the key codes obtained from curses.

Mikolaj commented 13 years ago

I don't think this particular issue is properly resolved, especially that I claim it's a regression and you don't address the claim. But your comments were already helpful to me and I can understand if you just don't have the time. Please reopen the issue if you decide it's worth your and my time, after all.

skogsbaer commented 13 years ago

Ok, I reopened the issue, although I don't believe that it's really an hscurses issue. Did you check on the same machine and the same configuration that your problem is working with 1.3.0.2?

Mikolaj commented 13 years ago

Thank you. I tested it using LambdaHack now, with 1.4.0.0 and 1.3.0.2 and, how embarrassing, the behaviour is the same as in 1.4.1.0, that is, xterm produces escape sequences instead of numbers with Shift+keypad. So, there is no regression in hscurses; your intuition was right.

About my other statements in the original issue report, I confirm almost all, in particular bash in xterm (and Gnome Terminal) produces correct numbers with Shift+keypad (either they catch the escape sequences or set up xterm somehow). I mixed up LambdaHack behaviour under Gnome Terminal though: under all hscurses versions it behaves opposite to xterm, namely Shift+keypad correctly produces numbers, but keypad without shift, for a couple of keys, produces unknown escape sequences.

Changing the X keyboard configuration did not help, so that's probably a regression in xterm (which does not affect vty nor bash, confusingly). I don't have access to my older machines right now to try and bisect xterm versions and make absolutely sure it's also not a regression in any other Haskell packages (ghc itself is 6.12.3, the same as before). If I figure it out later, I'll drop here a line. Closing.