Bug 1119764
Summary: | home and end keys not working properly | ||
---|---|---|---|
Product: | [Fedora] Fedora | Reporter: | Peter Backes <rtc> |
Component: | ncurses | Assignee: | Kevin Fenzi <kevin> |
Status: | CLOSED NOTABUG | QA Contact: | Fedora Extras Quality Assurance <extras-qa> |
Severity: | unspecified | Docs Contact: | |
Priority: | unspecified | ||
Version: | 25 | CC: | christoph.wickert, egmont, kevin, mlichvar |
Target Milestone: | --- | Keywords: | Reopened |
Target Release: | --- | ||
Hardware: | Unspecified | ||
OS: | Unspecified | ||
Whiteboard: | |||
Fixed In Version: | Doc Type: | Bug Fix | |
Doc Text: | Story Points: | --- | |
Clone Of: | Environment: | ||
Last Closed: | 2017-06-02 19:05:21 UTC | Type: | Bug |
Regression: | --- | Mount Type: | --- |
Documentation: | --- | CRM: | |
Verified Versions: | Category: | --- | |
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
Cloudforms Team: | --- | Target Upstream Version: | |
Embargoed: |
Description
Peter Backes
2014-07-15 13:00:36 UTC
This behaves as you expect in other terminals? roxterm, gnome-terminal, konsole, etc? (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 % 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... 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? 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. Upstream ticket: https://bugzilla.gnome.org/show_bug.cgi?id=600659 (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? 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. (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. 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. 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. Bug is still there as of F25 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. |