Red Hat Bugzilla – Bug 134300
artifacts when running with TERM=xterm and lynx
Last modified: 2007-11-30 17:10:50 EST
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.2)
Description of problem:
Log in to a gnome session, start a gnome terminal from the start menu
(Start/System Tools/Terminal), start lynx, go to
http://184.108.40.206/pub/linux/, and go to the parent directory (or do
any other navigating). You'll notice that the screen only partially
erases itself, leaving text from the previous screen that is cleaned
up when you hit ctrl-l.
The cause of the problem: TERM=xterm, COLORTERM=gnome_terminal
I tried changing TERM to 'gnome_terminal', but that entry was not
found in /usr/share/terminfo/g/, lynx would not start, vim resorted to
a builtin fallback terminal.
By changing TERM to 'gnome', lynx started, vim started, and the visual
barfage was gone. By changing TERM to 'vt100', same thing, although
I tried fiddling with COLORTERM, but neither lynx nor vim used it. If
the TERM was set to 'asdf' and COLORTERM to 'vt100', lynx complained
that it couldn't open 'asdf' and vim fell back to builtin ansi.
Recommendation: make gnome-terminal set the TERM environment variable
to gnome instead of xterm, or vt100 if gnome is not found in
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1. start gnome-terminal
2. lynx http://220.127.116.11/pub/linux/
3. go to parent directory
Actual Results: Visual barfage, fixed with ctrl-l
Expected Results: A perfect display of a directory.
See description, but basically, set TERM=gnome instead of xterm, or
vt100. gnome-terminal doesn't exist in /etc/termcap or in
TERM=gnome cannot be set, breaks too many other things.
*** This bug has been marked as a duplicate of 122815 ***
Fine, make it TERM=vt100, it doesn't mess up the screen like xterm does.
re-opening as per request in bug 122815.
note that this may be re-closed if gnome-terminal is deemed to work
correctly only when TERM=gnome and perfect xterm emulation is not a goal.
Strange, the scrolling problem in mutt related to indn and rin is
fixed in the gnome-terminal in fc3test, but this isn't. To make things
very clear this is a gnome-terminal bug and not a ncurses or lynx
bugs, things work fine in a real xterm.
As the original poster, I just want to be clear on this:
It's a fresh install of FC3-test2
It's the first time logged in to the root account
It's the default terminal emulator
and lynx and vim (maybe others, I didn't check) have problems.
I don't care if the terminal type is xterm or gnome-terminal or gnome
or vt100 or dr_suess_green_eggs_and_ham.
I just want everything to work perfectly for new sysadmins. I want
them to say "I installed FC3 and it works perfectly", not "I installed
FC3 and it has a few little glitches, nothing major".
I take that back about the terminal type. It's also necessary to be
able to ssh to another machine (non-FC3 but still unix/linux) and not
have that machine say "TERM=gnome? What's that?"
You *know* what it takes to do these two things.
1) set TERM=xterm (it does this already)
2) emulate xterm without the glitches.
For backwards compatiblity (sigh), it needs to handle TERM=gnome cases
with the current (not-exactly-xterm) emulation.
I know gnome-terminal can't tell what children's environment variables
are set to; it's going to have to watch for xterm-only or gnome-only
escape sequences to decide what mode it needs to emulate.
With this fixed, we can help give people a glitch-free operating
system, which is the whole point of the exercise.
Sorry, the comment:
> note that this may be re-closed if gnome-terminal is deemed to work
> correctly only when TERM=gnome and perfect xterm emulation is not a
made me a little rant-y.
I can confirm that there are still problems with lynx in
gnome-terminal in the latest development tree, but the problems there
used to be with mutt are fixed with FC3-test3.
Please retest vim against the latest FC3 (gold?) and if your problems
are still there please describe them, sofar you've only described your
lynx problems, which are reproducable. If you want your vim problems
fixed too, you need to make them reproducable.
Hmmm... maybe I made the vim stuff up. I can't seem to find an
example of it glitching.
I've got a clue: if you start gnome-terminal from an other terminal
and then start lynx and reproduce the bug you get:
** (gnome-terminal:11767): WARNING **: No handler for control sequence
Given that "initiate-hilite-mouse-tracking" and "scroll-up" are very
similar sequences, this seems like vte is misidentifying what lynx is
asking for. Does the warning still occur for you with 0.11.11-13?
Note i'm just asking about the warning, note the actualy bug.
When I said "scroll-up" i actually meant "scroll-down". Investigating this
further, I have a slightly better idea what's going on:
initiate-hilite-mouse-tracking's pattern is:
and scroll-down is:
What's happening is before vte adds the patterns to its table, it explicitly
collapses those patterns into the same pattern, namely "^[[PmT"
Right now, I'm not sure why code was added to coalesce numeric parameters to Pm
like that, but commenting it out causes side effects because some of the other
control sequence patterns depend on the Ps => Pm conversion (like
set-scrolling-region and cursor-position).
vte doesn't support initiate-hilite-mouse-tracking right now anyway so the
workaround fix for now will be to just remove that from its capabilities list.
I still get the warning with 0.11.11-13
I added the workaround I reported in Comment 11 to vte-0.11.11-14 in
rawhide, so things should work noticeable better now. Still haven't
the root of the problem, which is the Ps => Pm conversion. I'll
probably ask Nalin about that on Monday to see if he has any insights.
This was fixed a while ago, closing...
In gnome-terminal-2.7.3-1 on FC3 it still sets TERM=xterm and yet it isn't fully
compatible with xterm. Is gnome-terminal supposed to be fully xterm compatible?
*** Bug 141324 has been marked as a duplicate of this bug. ***