Note: This is a beta release of Red Hat Bugzilla 5.0. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Also email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback here.
Bug 79153 - vte does not handle some basic xterm movement control chars
Summary: vte does not handle some basic xterm movement control chars
Keywords:
Status: CLOSED RAWHIDE
Alias: None
Product: Red Hat Linux
Classification: Retired
Component: vte
Version: 8.0
Hardware: i386
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Nalin Dahyabhai
QA Contact:
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2002-12-06 14:36 UTC by Sean E. Millichamp
Modified: 2008-05-01 15:38 UTC (History)
1 user (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2003-01-09 22:17:42 UTC


Attachments (Terms of Use)

Description Sean E. Millichamp 2002-12-06 14:36:14 UTC
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.1) Gecko/20021003

Description of problem:
According to at least two different documents and one terminfo file I have
access to and empirical data xterm-compatible terminals should respond to the
following control codes:
Cursor up 1 time: \E[A
Cursor down 1 time: \E[B
Cursor forward 1 time: \E[C
Cursor back 1 time: \E[D

These should also work with an optional number immediately preceding the A, B,
C, or D indicating the number of times the cursor should move and if not
specified 1 should be the default.

This works exactly as expected in xterm.

There also appear to be other problems relating to screen drawing which I can't
diagnose until I have redefined the terminal I am using to work with vte's idea
of cursor moves (once I figure out what those are).


Version-Release number of selected component (if applicable):


How reproducible:
Always

Steps to Reproduce:
1. Use gnome-terminal to access a system that uses the above definitions for
xterm cursor movement.
2. Try using the cursor
3. See the A B C D get passed to the application as entered text, apparently
untrapped and the cursors unusable.


Actual Results:  The application in question displayed the letters corresponding
to the cursor control codes in the field that was selected.

Expected Results:  The cursor should have moved to another field.

Additional info:

This may or may not be an obscure problem.  I don't know how most of the xterm
definitions are written these days (until I encountered this problem yesterday I
haven't looked at using control characters to control a terminal in over 15
years).  I came across this because I'm using a brain-dead commercial
application that requires a custom terminal definition - they chose to use the
above control sequences in the terminfo file.  It works fine with gnome-terminal
1.4.0.4 and xterm. Even though I can and probably will rework the custom
terminfo file once I figure out what it needs I'd still classify it as a bug.

Comment 1 Sean E. Millichamp 2002-12-06 17:22:31 UTC
Okay, I recreated a new terminfo entry for the application following the xterm
definition shipped with RHL and I'm not convinced that the problem is exactly
what I had described but I am convinced there is a problem (as evidenced by
xterm working perfectly and g-t not at all).

I did some tcpdumps of the conversations between the functioning xterm and the
not-functioning g-t.  xterm transmits in the style \E[A while g-t transmits
\E0A.  If I checked g-t 1.x with zvt I'd bet it uses \E[A too.  Similarly for
the other cursor keys.

If the goal is to be xterm-compatible then I'd say it should be changed to match
/usr/X11R6/bin/xterm

Comment 2 Nalin Dahyabhai 2003-01-09 21:27:38 UTC
I'm not completely certain I understand what's going on here.  Is the
application outputting the control sequence which the terminal doesn't
understand, or is the terminal sending an incorrect sequence to the application
when you press one of the arrow keys?

Comment 3 Sean E. Millichamp 2003-01-09 21:58:09 UTC
The terminal is sending an incorrect sequence when the arrow keys are pressed.

By "incorrect", I mean something that is not consistent with xterm.  The control
sequence sent by xterm for the up arrow key is "^[[A".  For gnome-terminal it is
"^[0A".

Note that this seems to be fixed in my limited testing of gnome-terminal that is
shipped in phoebe.  "Fixed" meaning the sequence transmitted by gnome-terminal
is once again consistent with xterm.

A very simple way I was using to see the differences is to run /bin/cat in xterm
and gnome-terminal and then press an arrow key, the resulting sequences are
different.


Comment 4 Nalin Dahyabhai 2003-01-09 22:17:42 UTC
Yes, that would make sense.  gnome-terminal in Phoebe gained an understanding of
XTerm keypad and cursor key modes (Sun/HP/Legacy/VT220 function key modes, too).
 Marking as resolved in Raw Hide.


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