https://bugzilla.novell.com/show_bug.cgi?id=727239 https://bugzilla.novell.com/show_bug.cgi?id=727239#c Andreas Jaeger changed: What |Removed |Added ---------------------------------------------------------------------------- AssignedTo|bnc-team-screening@forge.pr |sndirsch@suse.com |ovo.novell.com | -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

https://bugzilla.novell.com/show_bug.cgi?id=727239 https://bugzilla.novell.com/show_bug.cgi?id=727239#c2 --- Comment #2 from jorge aires 2011-11-03 21:56:07 UTC --- Hi Stefan, I though so too. And in fact I began by submitting the bug report to Chromium as I thought it was app specific. Then I noticed problems on Emacs. Firefox too is affected. Unlike chromium Ctrl+Kp-Pgup does change tab on Firefox, but press Shift+home to select a piece of text you're editing and you get a 1, even though num lock is off. So you may be right, of course. It just seems odd that so many apps would handle the numpad wrong. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

https://bugzilla.novell.com/show_bug.cgi?id=727239 https://bugzilla.novell.com/show_bug.cgi?id=727239#c4 --- Comment #4 from jorge aires 2011-11-04 12:35:49 UTC --- Hello Werner, I also considered that possibility but it seems desktop agnostic. My usual desktop is KDE and it persists when running IceWM instead. It is also not a problem with my user as I also tried it with newly created account. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

https://bugzilla.novell.com/show_bug.cgi?id=727239 https://bugzilla.novell.com/show_bug.cgi?id=727239#c6 --- Comment #6 from jorge aires 2011-11-04 14:03:43 UTC ---

Choose fvwm2 session and retry. It is a well known fact that KDE and the used themes may mask out some of the key strokes for some applications.

Sure, I understand, that's why I tried it under iceWM like I said before. Anyway just tried it under fvmw2 and also openBox, and it is reproducible in all of them. It makes no difference. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

https://bugzilla.novell.com/show_bug.cgi?id=727239 https://bugzilla.novell.com/show_bug.cgi?id=727239#c8 Dr. Werner Fink changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEEDINFO |RESOLVED InfoProvider|jorge.adriano@gmail.com | Resolution| |UPSTREAM --- Comment #8 from Dr. Werner Fink 2011-11-04 15:20:27 UTC --- Hmm ... Ctrl-Prior man Crtl-Next works as it should in Emacs but you should note that Prior(aka PgUp) and Next (aka PgDown) are *not* identical with kp-prior and kp-next and therefore the keys Ctrl-kp-prior and Ctrl-kp-next requires an own mapping. If you want to have such a mapping you may report this upstream (see Help->Send Bug Report) then ... maybe this will be happen but if you add a correct patch with your report we will see thi with the next emacs version. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

https://bugzilla.novell.com/show_bug.cgi?id=727239 https://bugzilla.novell.com/show_bug.cgi?id=727239#c10 --- Comment #10 from jorge aires 2011-11-05 10:22:17 UTC --- (In reply to comment #1)

Jorge, as you can verify via xev Pgup/Pgdn/Home/End and Kp-Pgup/Kp-Pgdn/Kp-Home/Kp-End deliver different keycodes. It's up to the application to handle these the same or just different. Reassigning to Werner, since he's our maintainer for emacs.

Hi again Steffan, Sorry for bothering again, but there more than one 'problem' with the way the keypad is handled, and some are system wide and not application or DE specific. For instance, it appears that Shift+keypad-key is used to flip the num-lock state for that stroke. I.e., if numlock is OFF Shift+(1/home) will produce 1 and if it is ON it will produce Kp-Home. This is reproducible even in an xterm under fvwm2. It also happens in YaST, Firefox, Chromium, Emacs, Konversation, pretty much any KDE line input etc etc. I can only _not_ reproduce it in some text editors, such as Kwrite (kde) or Beaver (gnome). This behaviour is in my opinion a very poor choice, and it seems to be set system wide by default, and overridden by a few applications. Then we have the other kind of issues where certain specific apps do not handle key combinations involving keypad keys in a consistent form with regards to their non-keypad counterparts. It's the case with chromium Ctrl-kp-Pgup/Pgdn, or emacs Ctrl-kp-Home/End. Now regarding Home and Kp-Home producing different keycodes. Of course we may want to distinguish keys that are different so I can understand that, but only to the same extent that I can understand Left-Ctrl and Right-Ctrl being different. Yes it is nice to have the ability to remap them and assign them different functions, but by default I don't want to have to bother about whether I'm using Kp-Home or Home any more than I want to have to bother about pressing Left-Ctrl or Right-Ctrl. Windows gets this right. There's no issue with changing tab on Chrome under windows with Kp-Pgup. There's no issue with select text using Shift-Kp-Home. Everything works the way it is 'expected' to. So I don't know if this is a bug or a feature. But either way, it is very inconvenient. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.