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.
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
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?
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.
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.