GNOME Bugzilla – Bug 342645
Shift + numpad key produces a number even when numlock is off (which badly disrupts many convenient editing features).
Last modified: 2017-08-24 22:40:07 UTC
Being able to use the numpad keys to handle cursor movement, text selection, and clipboard operations while editing is extremely convenient. You can do everything.. - Cursor movement: Left, right, word left, word right, start of line, end of line, page up, page down, top, and bottom. - Text selection: Left, right, word left, word right, start of line, end of line, page up, page down, top, and bottom. - Clipboard operations: Cut, copy, and paste. ..all without looking down or moving your hand at all. Unfortunately, under Gnome/GTK, all the Selection and Clipboard functions cannot be accomplished using the numberpad keys, because when you hold down shift and press a numberpad key, a number (or a period) is produced even when the numlock is Off. I notice that in wxWidgets (using KeyEvent::GetKeyCode(), anyway) mumberpad keys are reported differently depending on wether the numlock is on or off. Under GTK, holding down shift produces the number version of the key to be reported even when numlock is off. This is not the case under MSW. Is there some operating system option I'm missing that controls this? Is this a duplicate bug? If so, my apologies. Other information:
There's also similar bug reports at Ubuntu For example here: https://bugs.launchpad.net/ubuntu/+source/xkeyboard-config/+bug/32768 I think that the misfeature is known more than I thought before. The option ""Shift with numpad keys works as in MS Windows." solves the problem partially. Lucky for me, Lazarus IDE I use on Linux has advanced key mappings dialog where I just added NUMPAD_0 as an alternative to Paste and it worked in the source editor. But standard edits in dialogs still lack Shift-{NumPad}Insert support
I've noticed this issue exists for a pretty long time, in diverse linux distributions, and it affects most of gnome applications. I guess this is a issue inside the base systems (probably Gtk?) of gnome. My solution is: use a wireless full 101-key keyboard, instead of the small one on laptop, or buy large laptops that has independent Home/End/PageUp/PageDown keys :)
I eventually noticed the original post was on 2006, and this issue still exists on six years later?!
I've always used a full 101-key keyboard (since the mid-to-late 80's, I think), and under Mac OSX and Linux (where I spend the majority of my time) I use the separated editing keys as is commonly suggested, but despite having had decades, now, to "get used to it", I have never found them to be a satisfactory replacement for the numpad editing keys. I've tried using OS scancode mapping features, Window Manager (Gnome) options, and various editor keyboard mapping features to try to get the numpad editing functions working correctly, but the results of these efforts has never really produced success (from my point of view). I might be wrong, but I suspect this issue is rooted in the kernel. The kernel's keyboard processing doesn't seem to be producing the correct keycodes depending on the state of the numlock key. Maybe one of these weekends I'll take some time to really dive into pages like this one: http://gunnarwrobel.de/wiki/Linux-and-the-keyboard.html .. and try to figure out what's going on and how to fix at least the kernel part of it. From there, maybe window manager and/or editor features can get the rest of the way. I'm not sure what this "unconfirmed" status means, but it seems like yet more evidence that no one but me cares about this At All. From the PC's early beginnings I've always noticed that practically everyone just leaves the numlock on all the time, and not that many people even know about the numpad editing key features, even under Windows, where they work. People even get mad at me for leaving the numlock off on my own keyboard! They go to use it for a minute and go to type one number or something, and they can't understand why the number pad "isn't working." "Oh my god, you left your numlock off! I hate people like you!" (What people like me? You actually met someone else who does it!? Who!? Where!? They can never tell me.) But I use numpad editing keys a Whole Lot more often than I use a number pad, and if I do need a number pad, I just flick the numlock on for a bit while I use it that way. In fact (when using Windows) I switch between the two numpad feature sets without even consciously thinking about it. To me, practically everyone is missing out in a huge way, but I seem to be one very lone wolf concerning this particular matter. I don't understand why more people don't know about this and use this more. It's so convenient, so effortless, so ergonomic.. it's.. fundamental. Linux lovers are often Windows haters, and their usual response to my complaint about this is to say "Oh, that's just the way Windows does it" but I don't agree with that at all. To me it's not "just the way Windows does it," it's the obvious way the keyboard numpad was designed to be used. Why have a numlock key if it doesn't do anything? Why paint arrows and Home/End/PgUp/PgDn/Ins/Del on the numpad keys if you can't use them for those purposes? And if you do make them useable for those purposes, why not make shift and control alter how they behave to add convenience features for word, line, page and document selection and cutting, copying and pasting? It's as though Linux and Mac OSX, while caving in to popular demand enough to at least nominally support the use of PC keyboards, stubbornly refuse to implement all the established conventions for their use, just to be different from Windows! But it has nothing to do with Windows, it is the obvious way that the PC keyboard hardware was designed to be used, and even today remains that way, for some reason, despite the fact that nobody but me seems to know or care. Alright, </rant>. Anyway, I guess it's probably not really a Gnome thing, it's probably more of kernel thing.
*** This bug has been marked as a duplicate of bug 158993 ***