Bug 79153

Summary:	vte does not handle some basic xterm movement control chars
Product:	[Retired] Red Hat Linux	Reporter:	Sean E. Millichamp <sean>
Component:	vte	Assignee:	Nalin Dahyabhai <nalin>
Status:	CLOSED RAWHIDE	QA Contact:
Severity:	medium	Docs Contact:
Priority:	medium
Version:	8.0	CC:	mitr
Target Milestone:	---
Target Release:	---
Hardware:	i386
OS:	Linux
Whiteboard:
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2003-01-09 22:17:42 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:

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.