Bug 65067 - Alt cursur/home/end sends 2x ESC + patch fixing this
Summary: Alt cursur/home/end sends 2x ESC + patch fixing this
Status: RESOLVED WORKSFORME
Alias: None
Product: konsole
Classification: Applications
Component: general (show other bugs)
Version: unspecified
Platform: RedHat Enterprise Linux Linux
: NOR normal
Target Milestone: ---
Assignee: Konsole Developer
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2003-09-28 02:36 UTC by Hans de Goede
Modified: 2006-08-07 15:00 UTC (History)
1 user (show)

See Also:
Latest Commit:
Version Fixed In:


Attachments
simple patch fixing the problem (509 bytes, patch)
2003-09-28 02:37 UTC, Hans de Goede
Details
patch adding seperate esc-sequences for modified grey/special/function keys (14.64 KB, patch)
2003-11-03 09:21 UTC, Hans de Goede
Details
new complete patch based on Hans' patches. (15.65 KB, patch)
2003-11-03 10:02 UTC, Helge Deller
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Hans de Goede 2003-09-28 02:36:04 UTC
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)
Comment 1 Hans de Goede 2003-09-28 02:37:09 UTC
Created attachment 2604 [details]
simple patch fixing the problem
Comment 2 Thiago Macieira 2003-09-28 02:46:32 UTC
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. 
Comment 3 Hans de Goede 2003-09-28 11:46:22 UTC
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).
Comment 4 Helge Deller 2003-11-02 22:38:52 UTC
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;


Comment 5 Stephan Binner 2003-11-03 09:03:48 UTC
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

Comment 6 Hans de Goede 2003-11-03 09:19:55 UTC
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.
Comment 7 Hans de Goede 2003-11-03 09:21:10 UTC
Created attachment 3002 [details]
patch adding seperate esc-sequences for modified grey/special/function keys
Comment 8 Helge Deller 2003-11-03 09:27:58 UTC
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;


Comment 9 Helge Deller 2003-11-03 09:34:33 UTC
reopen bug for now
Comment 10 Helge Deller 2003-11-03 10:02:44 UTC
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 ?
Comment 11 Hans de Goede 2003-11-03 12:04:06 UTC
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 !!
Comment 12 Hans de Goede 2003-11-17 12:18:50 UTC
Hi,

Did you receive my last mail and what is the current status?
Comment 13 Hans de Goede 2004-05-30 15:42:34 UTC
ping
Comment 14 Hans de Goede 2004-07-21 22:09:10 UTC
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.
Comment 15 Waldo Bastian 2004-07-21 23:46:45 UTC
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.
Comment 16 Hans de Goede 2004-07-21 23:58:41 UTC
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.
Comment 17 Robert Knight 2006-08-07 15:00:13 UTC
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.