Numpad input not recognised

[spacebiggles]

Hi. Have been using this to write a roguelike. Today when implementing diagonal movement, I found that I couldn't get term.KEY_LL and the such from the numpad. The upper right key is recognised as KEY_PGUP. It thinks that the 7 is KEY_ESC and seems to fail to read it as a sequence, producing multiple inputs. According to this http://stackoverflow.com/questions/16975367/ncurses-reading-numpad-keys-and-escaping, crawl hacks around it. Is there a way blessed can do similar? I had a go at monkey patching but it didn't go well.

[jquast]

Awesome report! I'm a huge fan of rogue-likes, very good luck to you, just the sort of thing blessed is designed to help with.

• Could you provide the $TERM value and Terminal emulator you are using?

calling curses's keypad() function simple writes some characters to your terminal emulator -- more than likely the '\x1b[?h', which is "DEC Private Mode Set (DECSET), Application Cursor Keys (DECCKM)".

I modified bin/test_keyboard_keys.py to do exactly that. And it does cause a different sequence of characters to be written:

• with: '\x1bOF', 360, KEY_END
• without: '\x1b[F', 360, KEY_END

I would suggest the fix is:

• new context manager, with term.keypad() ... that works like fullscreen, cbreak, etc.
• test and modify the "pre-loaded" database of blessed/keyboard.py (varible DEFAULT_SEQUENCE_MIXIN) which currently incorrectly maps \x1b[F to KEY_END, where it should instead be KEY_LL as you report.

and as a long-time nethack player, please also provide vi-like key option :)

[spacebiggles]

Cool! $TERM is xterm-256color on my machine and I'm using xfce-terminal. Sorry for omitting this in my original report, I was rushed to leave and wanted to make sure I actually submitted something.

The fix sounds pleasant to me. Will definitely include vi keys in the game, particularly once it's further down the track.

[jquast]

This is resolved, please see https://github.com/jquast/blessed/blob/master/bin/editor.py#L68 for an example of making use of directional keys whether numlock is on or off. If you pip upgrade to version 1.9.2 you'll be all set.

I'd like to point out that KEY_LL simply is not possible -- it is indistinguishable from KEY_PGDOWN in sequence, so it is not possible to "alias" or "sugar" it. When numlock is on, it is simply KEY_KP_1, representing its face value. It is not possible to "alias" or "sugar" it, though I did try.

You'll want to use the new context manager, "with keypad()".

[spacebiggles]

Cool, thanks. Works on my end. Numpad keys seem to come out at u'1' etc with numlock on, though, don't seem to have code KEY_KP_1. Also seem to get KEY_FIND on 1 and KEY_SELECT on 7 when numpad is off. I'm guessing that this is just quirks of different terminal types or something, so I I'll just test when/if it comes distribution time.

[jquast]

that's very interesting about KEY_FIND and KEY_SELECT, I was not able to "produce" those keycodes with my own, but I suspect my keyboard is quite different from yours, a "Kinesis Advantage", http://www.kinesis-ergo.com/shop/advantage-for-pc-mac/ on the mac, where the standard apple keyboards do not have a keypad in any form, so this is all I had to work with.

Its a good start though, at least they're captured now. I'll have to get a standard USB keyboard and try again with perhaps linux in the future and see if we can't make something congruent.

[jquast]

strange thing i found today in SyncTerm, was that its F5 key is mistaken for KEY_KP_4 !?

filed #43