Bug 1119764 - home and end keys not working properly
Summary: home and end keys not working properly
Keywords:
Status: CLOSED NOTABUG
Alias: None
Product: Fedora
Classification: Fedora
Component: ncurses
Version: 25
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Kevin Fenzi
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2014-07-15 13:00 UTC by Peter Backes
Modified: 2017-06-02 19:05 UTC (History)
4 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2017-06-02 19:05:21 UTC


Attachments (Terms of Use)

Description Peter Backes 2014-07-15 13:00:36 UTC
Description of problem:
home and end keys do not work properly in zsh with the standard bindkey   on ${terminfo[khome]} and ${terminfo[kend]}

Version-Release number of selected component (if applicable):
xfce4-terminal-0.6.3-1.fc20.i686
zsh-5.0.5-1.fc20.i686

How reproducible:
always

Steps to Reproduce:
1. open xfce4-terminal with zsh
2. bindkey  "${terminfo[khome]}"    beginning-of-line; \
bindkey  "${terminfo[kend]}"     end-of-line
3. type something, then press home and end keys

Actual results:
nothing happens

Expected results:
cursor jumps to beginning and end of line

Additional info:

found the following workaround:
bindkey  "\e[H"                  beginning-of-line
bindkey  "\e[F"                  end-of-line

What should really be sent according to terminfo is \eOF and \eOH:

% infocmp xterm | egrep -i 'HOM|END'
	flash=\E[?5h$<100/>\E[?5l, home=\E[H, hpa=\E[%i%p1%dG,
	is2=\E[!p\E[?3;4l\E[4l\E>, kDC=\E[3;2~, kEND=\E[1;2F,
	kHOM=\E[1;2H, kIC=\E[2;2~, kLFT=\E[1;2D, kNXT=\E[6;2~,
	kdch1=\E[3~, kend=\EOF, kent=\EOM, kf1=\EOP, kf10=\E[21~,
	kf8=\E[19~, kf9=\E[20~, khome=\EOH, kich1=\E[2~,
% infocmp xterm-256color | egrep -i 'HOM|END' 
	flash=\E[?5h$<100/>\E[?5l, home=\E[H, hpa=\E[%i%p1%dG,
	kEND=\E[1;2F, kHOM=\E[1;2H, kIC=\E[2;2~, kLFT=\E[1;2D,
	kcuu1=\EOA, kdch1=\E[3~, kend=\EOF, kent=\EOM, kf1=\EOP,
	kf8=\E[19~, kf9=\E[20~, khome=\EOH, kich1=\E[2~,

Comment 1 Kevin Fenzi 2014-07-16 23:58:45 UTC
This behaves as you expect in other terminals? 

roxterm, gnome-terminal, konsole, etc?

Comment 2 Peter Backes 2014-07-17 00:11:16 UTC
(In reply to Kevin Fenzi from comment #1)
> This behaves as you expect in other terminals? 
> 
> roxterm, gnome-terminal, konsole, etc?

Only tried gnome-terminal. gnome-terminal works correctly. Pressing home, then end, on a terminal running cat:

gnome-terminal:

% echo $TERM 
xterm-256color
% cat
^[OH^[OF^C
%

xfce4-terminal:

% echo $TERM
xterm-256color
% cat       
^[[H^[[F^C
%

Comment 3 Kevin Fenzi 2014-07-28 20:00:19 UTC
Can you please try roxterm or lxterminal or one of the vte based terminals?

gnome-terminal is using vte3. 

Trying to isolate if it's a vte or vte3 (or not related to them at all) issue...

Comment 4 Peter Backes 2014-07-28 23:05:09 UTC
roxterm seems to use vte3. Same behaviour as gnome-terminal.

lxterminal seems to use vte. Same behaviour as xfce4-terminal.

So I guess it's a vte issue.

Not reproducible with your setup?

Comment 5 Egmont Koblinger 2014-07-31 17:21:54 UTC
Note that xterm by default emits ^[[H and ^[[F, that is, it does not behave as described in terminfo.

vte3 (0.36) / vte291 (0.37) have been modified (they are in rawhide, to become fedora 21) to match xterm and emit ^[[H and ^[[F, just like your xfce4-terminal (using legacy vte) does.  Except in application cursor keys mode, where it emits ^[OH/^[OF, again, to match xterm.

Yes, this whole situation sucks big time.  I don't know what the proper solution would be.

Comment 6 Egmont Koblinger 2014-07-31 17:22:45 UTC
Upstream ticket: https://bugzilla.gnome.org/show_bug.cgi?id=600659

Comment 7 Peter Backes 2014-07-31 21:11:19 UTC
(In reply to Egmont Koblinger from comment #5)
> Note that xterm by default emits ^[[H and ^[[F, that is, it does not behave
> as described in terminfo.

seems you're right. So terminfo needs to be changed, I suppose?

Comment 8 Egmont Koblinger 2014-07-31 21:49:51 UTC
xterm has a tcapFunctionKeys resource.  When turned on, it changes Home/End to match terminfo (and I guess it changes the function keys too).  This clearly means that the maintainer of terminfo and xterm (these two are maintained by the same guy) is aware of the mismatch.  Maybe he could tell more about the history and rationale.  Unfortunately I don't know if changing terminfo would be the best solution or not.

Comment 9 Peter Backes 2014-07-31 22:22:16 UTC
(In reply to Egmont Koblinger from comment #8)
> xterm has a tcapFunctionKeys resource.  When turned on, it changes Home/End
> to match terminfo (and I guess it changes the function keys too).  This
> clearly means that the maintainer of terminfo and xterm (these two are
> maintained by the same guy) is aware of the mismatch.

Is that really true? termName can be used to change TERM, then probably tcapFunctionKeys can be used to ensure xterm sends the key codes expected according to its terminfo. So I don't think the existence of tcapFunctionKeys means that this mismatch is there on purpose... But it's speculation. It would certainly be something reasonable to ask the maintainer.

Comment 10 Fedora End Of Life 2015-05-29 12:22:32 UTC
This message is a reminder that Fedora 20 is nearing its end of life.
Approximately 4 (four) weeks from now Fedora will stop maintaining
and issuing updates for Fedora 20. It is Fedora's policy to close all
bug reports from releases that are no longer maintained. At that time
this bug will be closed as EOL if it remains open with a Fedora  'version'
of '20'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version.

Thank you for reporting this issue and we are sorry that we were not 
able to fix it before Fedora 20 is end of life. If you would still like 
to see this bug fixed and are able to reproduce it against a later version 
of Fedora, you are encouraged  change the 'version' to a later Fedora 
version prior this bug is closed as described in the policy above.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events. Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

Comment 11 Fedora End Of Life 2015-06-30 01:05:06 UTC
Fedora 20 changed to end-of-life (EOL) status on 2015-06-23. Fedora 20 is
no longer maintained, which means that it will not receive any further
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of
Fedora please feel free to reopen this bug against that version. If you
are unable to reopen this bug, please file a new report against the
current release. If you experience problems, please add a comment to this
bug.

Thank you for reporting this bug and we are sorry it could not be fixed.

Comment 12 Peter Backes 2017-06-01 20:01:45 UTC
Bug is still there as of F25

Comment 13 Peter Backes 2017-06-02 19:05:21 UTC
Ok, I figured out what the problem is.

See https://github.com/fish-shell/fish-shell/issues/2139#issuecomment-117548585 and in particular the list of links there.

Apparently the terminal has two modes, normal mode and application mode. Depending of the mode, home and end (but also the cursor keys) send different escape sequences.

terminfo specifies the escape sequences as sent in application mode. That is the mode which full screen applications typically use, for example vim. Application mode can be entered/left with an escape sequence that can be generated with tput smkx and tput rmkx, respectively. Normal mode, in contrast, is the default mode and the mode which zsh uses.

The zsh FAQ link specifies a solution, which is to enter application mode each time zsh expects input at the prompt. According to the thead linked above, this is how zsh is configured under debian by default. However, that is arguably not a nice solution, as zsh is not a full screen application.

Why do the cursor keys work? Because zsh by default binds both application and normal mode escape sequences for those, and doesn't bind home and end at all by default. bash also binds both sequences, including for home and end. So simply using my workaround from above should be okay.

I wonder why terminfo doesn't have normal mode sequences under different identifiers? At least, there is an extra terminfo entry xterm-noapp. Thus, one might put the following in .zshrc:

case "$TERM" in
xterm*)
bindkey "`tput -Txterm-noapp khome`" beginning-of-line
bindkey "`tput -Txterm-noapp kend`" end-of-line
;;
esac

Closing this as NOTABUG.


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