Bug 480489
| Summary: | Breaks cursor movement in vi | ||
|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | Enrico Scholz <rh-bugzilla> |
| Component: | xterm | Assignee: | Miroslav Lichvar <mlichvar> |
| Status: | CLOSED NEXTRELEASE | QA Contact: | Fedora Extras Quality Assurance <extras-qa> |
| Severity: | medium | Docs Contact: | |
| Priority: | low | ||
| Version: | 10 | CC: | dickey, mlichvar, pertusus |
| Target Milestone: | --- | ||
| Target Release: | --- | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Fixed In Version: | 242-2.fc10 | Doc Type: | Bug Fix |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2009-03-09 23:01:01 UTC | Type: | --- |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
problem still persists with upstream xterm 239. It can be workarounded by 'xterm -kt vt220'. 'xterm -kt tcap' produces the erronous behavior since 238; this option worked fine with 237. It does not seem to be an 64 bit issue (remotely executed xterm on an i386 machine shows same behavior). I can see bad behavior only with 'vim'; cursor movement in 'bash', 'mc', 'nano' is fine. vim uses the tcap-query feature, which is compiled-in by default since #238. I got a report dealing with colors, which ultimately was fixed by user's configuration. I'm not sure how it would break cursor keys, but suspect this is the place to look. On my machine - I have only a minimal .vimrc - it seems to work as expected. If that's where the problem lies, the feature can be disabled
via X resource setting (man xterm):
allowTcapOps (class AllowTcapOps)
Specifies whether control sequences that query the terminal's
notion of its function-key strings, as termcap or terminfo
capabilities should be allowed. The default is ``true.''
I'd like to know the particular issue if this is the case. But first
let's isolate it.
setting 'XTerm*allowTcapOps: false' fixes the issue xterm-242-2.fc10 has been submitted as an update for Fedora 10. http://admin.fedoraproject.org/updates/xterm-242-2.fc10 xterm-242-2.fc9 has been submitted as an update for Fedora 9. http://admin.fedoraproject.org/updates/xterm-242-2.fc9 xterm-242-2.fc10 has been pushed to the Fedora 10 testing repository. If problems still persist, please make note of it in this bug report. If you want to test the update, you can install it with su -c 'yum --enablerepo=updates-testing update xterm'. You can provide feedback for this update here: http://admin.fedoraproject.org/updates/F10/FEDORA-2009-2239 xterm-242-2.fc9 has been pushed to the Fedora 9 stable repository. If problems still persist, please make note of it in this bug report. xterm-242-2.fc10 has been pushed to the Fedora 10 stable repository. If problems still persist, please make note of it in this bug report. |
Description of problem: Recent 'xterm' upgrade breaks cursor movement by arrow keys in 'vim'. When using the 'xterm' binary from old xterm-237-1.fc10 in the same environment, things are as expected. Version-Release number of selected component (if applicable): xterm-238-1.fc10.x86_64 How reproducible: 100% Steps to Reproduce: 1. xterm 2. vim 3. i (enter insert mode) 4. abc 5. <left arrow> Actual results: cursor is at first char ('a') Expected results: cursor is at last char ('c') (that's the behavior for old xterm-237-1.fc10) Additional info: http://invisible-island.net/xterm/xterm.log.html#xterm_239 mentions fixed keyboard problems on 64 bit systems.