Bug 92749

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?