Version: (using KDE KDE 3.1.3) Installed from: RedHat RPMs Compiler: gcc OS: Linux Description of problem: konsole sends 2x escape for alt + cursor/home/end keys How reproducible: Konsole prefixes all key-sequences with an esc when alt (meta) is pressed. This is right for normal keys but wrong for keys which already send esc-sequences (cursor keys, function keys). Prefixing an esc-sequence with an esc leads to 2 esc's in one sequence 2 esc's normally is seen as an abort try: Steps to Reproduce: 1. Start mcedit in konsole 2. type something 3. press alt left or alt right or alt F6, etc Actual results: Save on quit yes/no/cancel Expected results: dunno, maybe go word left go word right (this happens in bash) but not the quit dialog box This also bites vi, joe, mc itself and probably other apps. Anyways its just plain wrong. (to send 2 esc's)
Created attachment 2604 [details] simple patch fixing the problem
I believe that the escape sequence for a Meta'ed key is to replace the [ with an O. That is, instead of ESC [ A, the sequence would be ESC O A.
Nope, The esc sequences fot a Metad'd key depend on the original esc sequence type for example: ESC [ 1 ~ -> ESC [ 1 ; 3 ~ ESC [ 4 ~ -> ESC [ 4 ; 3 ~ ESC [ A -> ESC [ 3 A ESC [ B -> ESC [ 3 B ESC O A -> ESC O 3 A ESC O B -> ESC O 3 B The difference between ESC O A and ESC [ A depends on wether the keypad is in application mode or not. But that is not the problem here, things like specifique ESC sequences for keypad keys with modifiers can be put in the keytab file, the problem is that ESC sequences without an explicit meta definition get an ESC prefixed and thats wrong (for an esc sequences).
Subject: kdebase/konsole/konsole CVS commit by deller: fix bug #65067, do not prefix key-sequences with an esc when alt (meta) is pressed for keys which already send esc-sequences. Thanks to Hans de Goede for the patch. CCMAIL: 65067-done@bugs.kde.org M +2 -1 TEmuVt102.cpp 1.106 --- kdebase/konsole/konsole/TEmuVt102.cpp #1.105:1.106 @@ -930,5 +930,6 @@ void TEmuVt102::onKeyPress( QKeyEvent* e if (cmd==CMD_send) { - if ((ev->state() & AltButton) && !metaspecified ) sendString("\033"); + if ( (ev->state() & AltButton) && !metaspecified && !(len && txt[0]==27) ) + sendString("\033"); emit sndBlock(txt,len); return;
Subject: Re: kdebase/konsole/konsole On Sunday 02 November 2003 22:38, Helge Deller wrote: > CVS commit by deller: > fix bug #65067, do not prefix key-sequences with an esc when alt (meta) is > pressed for keys which already send esc-sequences. This "No quit dialog in mcedit"-patch breaks eg word-wise navigation in Bash. I fail to see why Konsole should show another behavior as xterm/aterm/Eterm. Please revert. Bye, Steve
xterm/aterm/Eterm don't send 2x esc for alt + cursorkeys, they use special ESC-sequences for keypad / functionskeys with modifier keys. Try pressing ctrl+v and then alt left / right in bash in an official xterm (ctrl-v + key shows the true keysequence) The fact that someone has put esc sequences containing 2 esc's in your inputrc (readline keybindings file) means that your inputrc needs reconfiguring too, not that this patch is wrong! Besides that ctrl left/right should do word skipping not alt left/right. I'll attach another patch which adds seperate esc-sequences for modified keypad and function keys. Warning: -this patch was made for RedHat, which follows the debian keyboard guidlines for terminals and thus uses different esc-sequences for home/end then the default xterm/konsole, you probably don't want this part of this patch, then again maybe you do since at least both redhat and debian make these changes. Note: -this patch uses slightly different esc-sequences for the cursorkeys+modifiers then xterm does, instead it uses the one send by gnome-terminal and already send by konsole for shift home/end/delete, which now are also send for different modifiers and different keys.
Created attachment 3002 [details] patch adding seperate esc-sequences for modified grey/special/function keys
Subject: kdebase/konsole/konsole CVS commit by deller: cvsrevertlast: the patch broke eg word-wise navigation in bash. CCMAIL: 65067@bugs.kde.org M +1 -2 TEmuVt102.cpp 1.107 --- kdebase/konsole/konsole/TEmuVt102.cpp #1.106:1.107 @@ -930,6 +930,5 @@ void TEmuVt102::onKeyPress( QKeyEvent* e if (cmd==CMD_send) { - if ( (ev->state() & AltButton) && !metaspecified && !(len && txt[0]==27) ) - sendString("\033"); + if ((ev->state() & AltButton) && !metaspecified ) sendString("\033"); emit sndBlock(txt,len); return;
reopen bug for now
Created attachment 3003 [details] new complete patch based on Hans' patches. This patch incoporates both previous patches and applies cleanly to CVS HEAD (which patch #3002 didn't). Comments ?
Looks good, but: WARNING: You're changing the esc-sequences send by home/end (even when not pressed with a modifier key) This might bite people!!, then again it brings konsole in line with redhat & debian keyboard guidelines and with gnome-terminal. But there are ofcourse other OS / distros out there which may not like this change. There is no right answer to this, but be aware that you are changing the default !!
Hi, Did you receive my last mail and what is the current status?
ping
Hi, There has been some heavy discussion about xterm, terminfo and xterm clones (such as konsole) on Fedora's bugzilla, see: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=122815 As a result of this it has been decided that not debian keyb guidelines or what RH /FC used todo in the past count, but that the only thing which counts is what the current real xterm does. So the current esc-sequences send for home and end by konsole are CORRECT. This makes my patch which adds modifier support to the keypad and Function keys WRONG since it changes the esc-sequences send by home and end The original double-esc patch however stlll is CORRECT and really should be applied. Having bindings in /etc/inputrc which contain esc-sequence which start with esc esc as Steven from Comment 5 has is simply dead wrong. The fact that he and perheps others have come to rely on a bug, doesn't mean the bug shouldn't be fixed. In order for Steven and others to be able to still get word forward backward capibilities using modifier + arrow, konsole need to be modified to send seperate esc-sequences for modified keys, and these seperate esc-sequences should then be added to /etc/inputrc (they might even already be there for the real xterm) My second patch can easily be fixed to not change the esc-sequences for home and end and thus become correct. BUT there is another problem with my second patch: the real the xterm and gnome-terminal are also cabable of sending seperate esc sequences for modifier combinations, basicly they have a 3 bit number taking a bit for each modifier and then put the decimal value of this number in the esc-sequence, for konsole to mimick this it needs either: -9 entries in the keymap file for each key, so around 200 entries -or the capability to specify that this key can have modifiers with say an X or * or someother handy char in the esc-sequence which the konsole code then replaces by the modifier number Which way do you want to go? p.s. konsole also shouldnot send ascii-del (\177) for backspace but CTRL-H, since that is what the real xterm does.
Good to see that I'm not the only one who thinks this terminfo stuff is a mess. The 'X' or '*' approach seems more efficient.
Waldo, I agree, do you know your way around the konsole code, and if so could you give me a few pointers where I should drop this in the code, then I'll try to write a patch.
Not reproducible here in KDE 3.5.3 or Konsole for KDE 4. I presume either the patch was applied at some point since the last comment or it was fixed another way.