Version: (using KDE KDE 3.3.0) Installed from: RedHat RPMs OS: Linux There are number of incompatibilities between konsole and xterm for convience I'm listing them all here, lett me know if you want any in a seperate bug. Alse see: http://bugs.kde.org/show_bug.cgi?id=65067 Where some of this has already been discussed. Key (esc) sequence incompatibility: -Konsole by default sends ASCII DEL instead of CTRL-H (^H), which is the official xterm default. -The ESC sequences send for home and end keys with modifier differ from those send by the official xterm. -The ESC sequences send for F1 - F12 with modifiers don't honor combinations of modifiers like xterm does, see http://bugs.kde.org/show_bug.cgi?id=65067 -Konsole doesn't send distuingish between cursor keys, insert, page-up and page-down without and with modifiers (alt, ctrl, shift). The official xterm has different ESC sequences for these keys with modifiers, like the F-keys have.
Created attachment 9832 [details] Patch fixing the described inconcistencies It took some time before I had time to write the fix, and then writing it also took some more time then I had estimated, but here it is (see attachment). The patch really consist of 3 parts: 1) modify keytrans.cpp & .h To learn the keytab modifier word AnyMod, this because the real xterm can also report combinations of modifiers for certain keys, so we either need 8 keytab lines per key or a special keyword for this. 2) modify the default keytab to use the new keyword and fix all bugs decribed above. 3) since backspace now sends ^H (like the real xterm) the tty erase character needs to be changed from the default ^? to ^H, this wasn't possible in the old konsole code, thus I added the following: -a setErase member to the TEPty class -a getErase member to the TEmuVt102 class and to the TEmulator superclass -added code to session.cpp which ties these 2 together That's all folks, please apply!
Thanks for the patch, although you really need to have a diff against the current HEAD. A whole lot of stuff has changed between 3.3.2 and 3.4. Were you planning on update all the other .keytab files?
Erm, I'm not a KDE developer, but a Fedora volunteer as such I did the diff against the latest Fedora SRPM. Afaik these parts of konsole haven't changed in ages, could you see if the current patch will apply without to much hassle? About other keytabs, I don't think the new AnyMod keyword is needed for the other keytabs, afaik xterm from xfree 3.3 and the console don't have seperate esc-sequences for grey keys with modifiers.
Created attachment 10042 [details] Same patch but this time against 3.4.0rc1 As requested the patch against 3.4.0rc1. Warning not tested /compiled yet, but it should work fine :) ping?
Created attachment 10061 [details] Small bugfix to patch against 3.4.0rc1 I've made some time today to actually test the patch and caught one small error which got in there (shift without a starting capital in README.default.Keytab). During testing I also noticed some strange other things, the changes made to README.default.Keytab in revision 1.30, see: http://webcvs.kde.org/kdebase/konsole/other/README.default.Keytab?rev=1.31&view=log Are strange to say the least, the real xterm doesn't do send ESC-sequences with lowercase a-d for shifted cursor keys when in AppScreen mode. Some more research got me to rxvt which does send ESC-sequences with lowercase a-d for shifted cursor keys, but always does this independend of AppScreen mode. Also shift left/right are bound to cycling through the tabs in 3.4.0rc1 konsole, so adding keybindings for shifted left/right is useless since shifted left/right keypresses never get to the TEmuVt102 object since they are caught by the UI. Disabling use of shift up/down/page up/page down for scrolling and make them sending the normal modifier pressed ESC-sequences when in AppScreen mode makes sense. xterm actually doesn't use shift up down and always sends the normal modifier pressed ESC-sequences for these. Since xterm (the real one) doesn't send any special ESC-sequences for cursor keys when in AppScreen mode I believe neither should konsole in its builtin Keytab, especially since this is called XFree 4.x which suggest it behavious as the latest real xterm. Also strange are the ESC-sequences send by shift page up/down when in AppScreen mode, these resemble the normal modifier pressed ESC-sequences but are missing the trailing ~ Summarising I suggest to: -make shift cursor and page down/up send the normal modifier pressed ESC- sequences when in AppScreen mode -do nothing for shift cursor left/right since these are caught by the UI and remove the unused entries from README.default.Keytab The original AppScreen mode related changes were made by someone with the CVS id waba, it would be nice if he could be contacted about this bug so that we can resolve this quickly.
waba is Waldo Bastian, the previous maintainer of Konsole. Go ahead and provide a patch for what you think it should be. I haven't spent anytime looking at this yet. I'll try to piece through it and commit it.
Created attachment 10330 [details] Patch fixing the described problems After some carefull thinking I've come to the conclusion that disabling the scrolling hotkeys when in AppScreen mode is a good thing and thus I've left this unchanged. But making the now (in Appscreen mode) unused shift cursor/page up/down keys send the standard esc sequences for these keys with modifiers is not a good thing, the end user doesn't know when an application puts the terminal in AppScreen mode, disabling scrolling in this case is fine, but what if the user still tries to scroll, the last thing he/she will expect is that all of a sudden the key-combi's which normally scroll are send to the application running under the terminal causing who knows what. Thus I've removed the special bindings for these key-combis when in AppScreen mode, making them dead which matches the real xterm. This results in this much cleaned up and hopefully last patch which amazingly looks a lot like the first one against 3.3.2 :)
How do you test this stuff? Do you have some program that you use or a program that shows the output of keystrokes?
If you type ctrl-V in a terminal (bash prompt) then the first character typed afterwards is shown literal, so backspace for example is shown as ^H or ^? instead of rubbing out a char. Since all cursor/function keys are esc sequences (normal strings prefixed with ESC) pressing ctrl-V + function key will give you the esc-sequence the ESC is shown as ^[ the rest is normal text and shown as such.
Created attachment 10706 [details] Patch fixing the described inconcistencies I've also submitted this patch for inclusion into Fedora some discussion there has lead to the conclusion that it is best to keep ASCII-DEL as the character send by the backspace key, instead of changing it to CTRL-H. This latest version of this patch thus removes the changes to backspace, also removing the only controversial part of this patch, it is now 99.99% save to apply.
I'm not ignoring you. :-) I was waiting on the subversion move to create a new branch to test your patch.... the move is taking longer than I thought it would. :-( It would be nice to have a program which would mimic the Ctrl-V in Bash. That is you could press all the keys in a row and it would display the keys (ie. ^[OP ). It would be easier to see what changes are taken place.
SVN commit 411235 by hindenburg: Fix some keyboard incompatibilities between konsole and real xterm. Thanks for the patch! BUG: 92749 M +16 -0 trunk/KDE/kdebase/konsole/konsole/TEPty.cpp M +1 -0 trunk/KDE/kdebase/konsole/konsole/TEPty.h M +14 -0 trunk/KDE/kdebase/konsole/konsole/TEmuVt102.cpp M +2 -0 trunk/KDE/kdebase/konsole/konsole/TEmuVt102.h M +5 -0 trunk/KDE/kdebase/konsole/konsole/TEmulation.cpp M +2 -0 trunk/KDE/kdebase/konsole/konsole/TEmulation.h M +50 -52 trunk/KDE/kdebase/konsole/konsole/default.keytab.h M +25 -2 trunk/KDE/kdebase/konsole/konsole/keytrans.cpp M +2 -0 trunk/KDE/kdebase/konsole/konsole/keytrans.h M +2 -0 trunk/KDE/kdebase/konsole/konsole/session.cpp M +53 -56 trunk/KDE/kdebase/konsole/other/README.default.Keytab
Hans, any comment on bug: 108547?