Bug 480489 - Breaks cursor movement in vi
Breaks cursor movement in vi
Status: CLOSED NEXTRELEASE
Product: Fedora
Classification: Fedora
Component: xterm (Show other bugs)
10
All Linux
low Severity medium
: ---
: ---
Assigned To: Miroslav Lichvar
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2009-01-17 12:41 EST by Enrico Scholz
Modified: 2009-03-09 19:01 EDT (History)
3 users (show)

See Also:
Fixed In Version: 242-2.fc10
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2009-03-09 19:01:01 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Enrico Scholz 2009-01-17 12:41:36 EST
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.
Comment 1 Enrico Scholz 2009-01-18 05:48:01 EST
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.
Comment 2 Thomas E. Dickey 2009-01-18 06:34:34 EST
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.
Comment 3 Thomas E. Dickey 2009-01-18 06:38:45 EST
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.
Comment 4 Enrico Scholz 2009-01-18 08:31:12 EST
setting 'XTerm*allowTcapOps: false' fixes the issue
Comment 5 Fedora Update System 2009-03-02 08:12:37 EST
xterm-242-2.fc10 has been submitted as an update for Fedora 10.
http://admin.fedoraproject.org/updates/xterm-242-2.fc10
Comment 6 Fedora Update System 2009-03-02 08:12:41 EST
xterm-242-2.fc9 has been submitted as an update for Fedora 9.
http://admin.fedoraproject.org/updates/xterm-242-2.fc9
Comment 7 Fedora Update System 2009-03-02 12:02:51 EST
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
Comment 8 Fedora Update System 2009-03-09 18:45:37 EDT
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.
Comment 9 Fedora Update System 2009-03-09 19:00:43 EDT
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.

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