Note: This is a public test instance of Red Hat Bugzilla. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback at bugzilla.redhat.com.
Bug 63473 - konsole emits wrong esc-sequences for home & end
Summary: konsole emits wrong esc-sequences for home & end
Keywords:
Status: CLOSED RAWHIDE
Alias: None
Product: Red Hat Linux Beta
Classification: Retired
Component: kdebase
Version: beta1
Hardware: i386
OS: Linux
high
medium
Target Milestone: ---
Assignee: Than Ngo
QA Contact: Ben Levenson
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2002-04-14 12:17 UTC by Hans de Goede
Modified: 2007-03-27 03:52 UTC (History)
0 users

Fixed In Version:
Clone Of:
Environment:
Last Closed: 2003-10-10 12:12:31 UTC
Embargoed:


Attachments (Terms of Use)
Patch fixing the described problems and also fixing bug 80651 (deleted)
2003-09-28 14:01 UTC, Hans de Goede
no flags Details | Diff

Description Hans de Goede 2002-04-14 12:17:36 UTC
Description of Problem:
konsole emits the wrong esc seqeunces for home and end.
This breaks for example home and end in mc

Key    Emitted sequence    Espected sequence
Home   ESC [ H             ESC [ 1 ~
End    ESC [ F             ESC [ 4 ~

Steps to Reproduce:
1. start konsole with a bash commandline
2. press CTRL-V
3. press a key, you get to see the ESC-sequence
4. do the same in xterm or gnome-terminal for the right sequences

Actual Results:
wrong esc-sequence

Expected Results:
right esc-sequence

Additional Information:

This is an old bug, with a known fix, but I can't find it probably because its
in bugzilla under the RH closed beta, I used to be a beta team member. And now
I'm not, so I can't see my own bugs, what irony :). Then again the fix is
probably completly different for kde3

Also xterm and gnome-terminal emit the ESC-sequences for F11-F20 for shfit
F1-F10, konsole emits the F1-F10 + modifier key ESC-sequences which newer
xterm's (but not the RH shipped version) emit. Which unfortunatly no
applications understand since this kinda info cannot be put in terminfo.
So maybe that should be fixed too, but thats less important.

Comment 1 Bernhard Rosenkraenzer 2002-04-15 16:27:20 UTC
Actually Esc [ F and Esc [ H are the correct sequences, the older variants  
(Esc [  1 ~ and Esc [ 4 ~) just happen to work as well.  
 
If you prefer the old sequences, go 
 
Settings -> Keyboard -> XTerm (XFree 3.x.x) 
 
Or am I overlooking something?

Comment 2 Hans de Goede 2002-04-15 18:03:04 UTC
As said, the current settings don't work in for example mc. This is because in
the 6.x days RedHat decided (and was correct in doing so) that xterm bindings
where a mess and should be standardised. In those days it was decided that home
and end send ESC [ 1 ~ and ESC [ 4 ~. This is what the RH shipped termcap /
terminfo say, even in skipjack beta 2 also since these days all RH shipped xterm
& friends send these ESC-sequences. But in skipjack beta2 both konsole and rxvt
are broken. But xterm and gnome-terminal still send these. This is btw also
according to the debian keyboard policy, and thus ensures compatibility when
telnetting to / from debian.

Also note that non XFree xterms (sun,hp) still send the old (and standard)
ESC-sequences. Way they ever changed is a mistery since this breaks telnet
between different versions, and for just that reason changing them now in the
middle of a stable RH series is a bad idea!

The very basics of terminals say that terminfo and the actual behaviour should
match. And for compatibilities sake, ESC sequences once chosen may never change,
new ones for new functionality may be added, but old ones should never change.


Comment 3 Hans de Goede 2002-05-06 05:31:46 UTC
Is anything going to actually happen with this bug, if this becames the new
default behaviour a lott of apps will break in one of the major terminals
shipped with RH, and RH travels back to the 5.x days on this aspect of usability.


Comment 4 Hans de Goede 2002-10-05 14:00:36 UTC
Still not fixed in 8.0. Bad, in the 7.0 / 7.1 times I and a few people at RedHat
spent a lott of time getting this right, and now the setup is broken again.

Lett me scream this:

A TERMINAL SHOULD SEND THE KEY (ESC) SEQUENCES THAT TERMCAP/TERMINFO SAY IT WILL
SEND FOR A CERTAIN KEY.

gnome-terminal gets it right, xterm gets it right, konsole is broken. Also note
that selecting the keyboard profile for xterm-xfree-3.3 will fail to because
this sends the correct sequences for home-end but the wrong ones for F1-F4 .

As I already said this is a known bug and was fixed in the past, this time I've
managed to find my old bug: bug 15682. It also contains 2 different fixes for
kde2, which very likely still apply to kde3.

Please fix this, not working keys like home and end are a MAJOR usabelity issue.
 You've know idea hoe many of my linux usign friends and students complain about
this.


Comment 5 Hans de Goede 2002-10-05 14:02:19 UTC
Onr last note I believe that the terminal behaviour should not be configurable
at all, but thats a different discussion. Please at least get the default setup
fixed.


Comment 6 Hans de Goede 2002-12-29 13:49:14 UTC
This bug is still there in Phoebe.

I can't find an example app since most apps seem to include a workaround but any
app using just ncurses (as intented) will fail because konsole sends ^[[F for
end instead of ^[[4~ same for home. Take a look at the redhat created
/etc/inputrc . Here end is binded to ^[[4~ . It also works in konsole because
inputrc contains a binding for ^[[F to for telnet from the freebsd konsole. So
this is just pure luck. Please fix this. Xterm end is supposed to send ^[[4~ and
home ^[[1~ this is an official RedHat point of view. So konsole is broken also
do "tput khome > log" and check the context of log. (tput uses ncurses / terminfo)



Comment 7 Hans de Goede 2002-12-29 14:14:55 UTC
I just tried:

mv /usr/share/apps/konsole/default.Keytab /usr/share/apps/konsole/default.keytab
(changing the extension from Keytab to keytab watch the case)

And then editing default.keytab unfortunatly this doesn't change the default
keytab but instead adds an extra entry to the settings->keyboard menu. So the
real defaults are hardcoded somewhere in the source :|

Also I've found 2 other keyboard related konsole bugs, which I will add to
bugzilla after a coffee break :)


Comment 8 Hans de Goede 2003-07-24 12:51:31 UTC
Still there in severn, I'm willing to write a patch for this and bugs 80650 and
80651, if you're willing to include it :)

Comment 9 Hans de Goede 2003-09-28 14:01:59 UTC
Created attachment 94801 [details]
Patch fixing the described problems and also fixing bug 80651

This patch touches the same files as kdebase-3.1.2-keydefs.patch, maybe they
should be merged? In any this one must be applied after that one!

Comment 10 Hans de Goede 2003-10-10 09:44:27 UTC
ping


Comment 11 Than Ngo 2003-10-10 12:12:31 UTC
Hi Hans, i have merged your patch in kdebase-3.1.4-keydefs.patch.
kdebase-3.1.4-3 should have this fix. Many thanks for your patch file.

>Still there in severn, I'm willing to write a patch for this and bugs 80650 and
>80651, if you're willing to include it :)

Please attach your patch file here, i will add it in next rebuild of course ;-)

Comment 12 Hans de Goede 2004-06-02 14:35:08 UTC
GRRR, this bug has resurfaced in FC2, see bug 124803.



Note You need to log in before you can comment on or make changes to this bug.