Numeric keypad bindings no longer work
Closed this issue · 7 comments
Issue #42 states that this feature has been removed on purpose.
Any chance this could be re-instated as an option that is off by default? Num-keys are extremely important to all the muscle memory I've built up over decades. I imagine there are more of us BRIEF old-timers who would very much appreciate the num-keys to be optionally re-instated.
As a general rule, it seems like going out of one's way to restrict configuration flexibility in a product like a programmer's editor is unwise, especially given how picky, diverse, and technically capable us programmers tend to be. Issue #42 states that it was confusing some programmers. I'm hopeful that having the capability buried as an opt-in feature would be seen as an acceptable compromise between those who are confused by it, and those who rely on it.
This is not something new; the issue you're referring to (#42) was closed over 3 years ago when #44 was merged. If you're seeing a recent regression somehow, please let us know and re-open this issue and provide the necessary level of detail needed to reproduce the regression.
Numpad support is still a thing, but only when used as a numeric keypad; we support Num Lock.
Given the reasons this was removed (see original issues), and the fact we do support the numpad when it is actually a numeric keypad, I'm going to close this issue. If someone wants to work on PR for making the proposed opt-in support for "non-numpad numpad", feel free to do so 🙇♂️
Whether numlock is on or off, numpad keys return different scan codes and all programming editors I've used before allow them to be mapped uniquely. Even Atom used to do so. I realize #42 is quite old, but I am a new user to Atom and was surprised to find numpad keys un-configurable, especially after reading an internet tutorial on how to configure them in Atom (https://blog.wislon.io/posts/2014/07/14/atom-editor-bind-number-keypad). I was suggesting perhaps the feature be re-introduced in a way that wouldn't trip up anyone who expects numlock to be forever locked in the 'on' position.
Numpad support is still a thing - I realize I can type numbers with it. The issue is titled "Numeric keypad bindings no longer work" (as I imagine they once did in that tutorial post). I'm not saying I can't type numbers on the keypad. I'm saying I can't bind functions to the num keypad without remapping all numbers on the keyboard (and we all still need to type numbers)
Numpad support is still a thing - I realize I can type numbers with it. The issue is titled "Numeric keypad bindings no longer work" (as I imagine they once did in that tutorial post). I'm not saying I can't type numbers on the keypad. I'm saying I can't bind functions to the num keypad without remapping all numbers on the keyboard (and we all still need to type numbers)
If you use the Keybinding Resolver, while pressing one of the numpad keys, you will see that these keys are being registered as numpad0, numpad1, and so on. Therefore, you should be able to map to these keys specifically.
I see. This appears to work for 0-9. When numlock is active, the keybinding resolver reports numpad0 through numpad9. With numlock inactive I get up/down/left/right/etc... So with numlock active I can uniquely identify numpad number keys, and with numlock inactive they are ambiguous with up/down/left/right/etc.
That might be workable for me (though not ideal, as I use all other applications with numlock off). However, whether numlock is on or off, the numkeys for slash/star/minus/plus/enter are ambiguous with their non-numpad counterparts according to the keybinding resolver. Also, num-delete is ambiguous with period with numlock on, and ambiguous with delete with numlock off.
I apologize for not being more thorough in my original post. Num-star is the first key I rebind in any editor (to 'undo' - a BRIEF-ism) and this was the source of my numpad issues in Atom. In particular, num-star, num-plus, num-minus, and num-insert are of high importance to me as BRIEF keys.
The tutorial at https://blog.wislon.io/posts/2014/07/14/atom-editor-bind-number-keypad looks like exactly what I'm looking for. I wish this capability were still accessible, but I respect that an editor can't always be everything to every one. I would be a grateful user if it could be replaced somehow.
@eric-777 You can assign a custom keystroke resolver in your Atom init script to customize how Atom maps a given DOM keyboard event to a keystroke string.
There is probably some state in the event you could use to treat the numeric keypad keys specially. Logging the events to the console should give you a quick idea of whether what you're after is possible via DOM APIs.
You can check the location of the event
To your init scipt:
atom.keymaps.addKeystrokeResolver ({event}) ->
if event.location is 3
return add-my-resolver-here@nathansobo Thankyou!!!!! I followed that link, researched how to add a keystroke resolver to init.coffee, and I have exactly what I'm looking for now. All numpad keys are now uniquely configurable, and behave identically whether numlock is on or off. I didn't realize you could hook the input any lower than the keymap.cson file.
In case anyone else is looking for the same thing, I've added the following to my init.coffee:
atom.keymaps.addKeystrokeResolver ({event}) ->
if event.type is 'keyup' or event.code[0] isnt 'N'
return ""
if event.code is "Numpad0"
return "num_0"
if event.code is "Numpad1"
return "num_1"
if event.code is "Numpad2"
return "num_2"
if event.code is "Numpad3"
return "num_3"
if event.code is "Numpad4"
return "num_4"
if event.code is "Numpad5"
return "num_5"
if event.code is "Numpad6"
return "num_6"
if event.code is "Numpad7"
return "num_7"
if event.code is "Numpad8"
return "num_8"
if event.code is "Numpad9"
return "num_9"
if event.code is "NumpadDivide"
return "num_slash"
if event.code is "NumpadMultiply"
return "num_star"
if event.code is "NumpadSubtract"
return "num_minus"
if event.code is "NumpadAdd"
return "num_plus"
if event.code is "NumpadEnter"
return "num_enter"
if event.code is "NumpadDecimal"
return "num_delete"
The event.code parameter was sufficient for distinguishing numpad keys from non-numpad keys. If this function returns a non-empty string, that string is preferentially used to index the keymap. I'm sure that's oversimplified, it's just my current understanding.