Note: This is a public test instance of Red Hat Bugzilla. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback at bugzilla.redhat.com.
Bug 134300 - artifacts when running with TERM=xterm and lynx
Summary: artifacts when running with TERM=xterm and lynx
Keywords:
Status: CLOSED RAWHIDE
Alias: None
Product: Fedora
Classification: Fedora
Component: gnome-terminal
Version: 3
Hardware: All
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Ray Strode [halfline]
QA Contact:
URL:
Whiteboard:
: 141324 (view as bug list)
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2004-10-01 05:19 UTC by Penelope Fudd
Modified: 2007-11-30 22:10 UTC (History)
9 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2005-02-16 16:17:29 UTC
Type: ---
Embargoed:

Attachments (Terms of Use)

Description Penelope Fudd 2004-10-01 05:19:39 UTC 
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.2)
Gecko/20040809 Epiphany/1.3.8

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://152.2.210.109/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
black-and-white.

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
t/usr/share/terminfo/g/.

Version-Release number of selected component (if applicable):
gnome-terminal-2.7.3-1

How reproducible:
Always

Steps to Reproduce:
1. start gnome-terminal
2. lynx http://152.2.210.109/pub/linux/
3. go to parent directory
    

Actual Results:  Visual barfage, fixed with ctrl-l

Expected Results:  A perfect display of a directory.

Additional info:

See description, but basically, set TERM=gnome instead of xterm, or
vt100.  gnome-terminal doesn't exist in /etc/termcap or in
/usr/share/terminfo.
Comment 1 Bill Nottingham 2004-10-01 23:22:40 UTC 
TERM=gnome cannot be set, breaks too many other things.

*** This bug has been marked as a duplicate of 122815 ***
Comment 2 Penelope Fudd 2004-10-07 19:50:08 UTC 
Fine, make it TERM=vt100, it doesn't mess up the screen like xterm does.
Comment 3 Eido Inoue 2004-11-04 22:23:10 UTC 
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.
Comment 4 Hans de Goede 2004-11-05 13:01:41 UTC 
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.
Comment 5 P Fudd 2004-11-07 10:09:13 UTC 
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.

Thanks!
Comment 6 P Fudd 2004-11-07 10:11:36 UTC 
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 
> goal.

made me a little rant-y.
Comment 7 Hans de Goede 2004-11-07 15:52:15 UTC 
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.
Comment 8 P Fudd 2004-11-08 04:04:40 UTC 
Hmmm... maybe I made the vim stuff up.  I can't seem to find an
example of it glitching.
Comment 9 Hans de Goede 2004-11-11 20:05:31 UTC 
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
`initiate-hilite-mouse-tracking' defined.
Comment 10 Ray Strode [halfline] 2004-11-11 20:38:37 UTC 
Hi Hans,

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.
Comment 11 Ray Strode [halfline] 2004-11-11 22:04:40 UTC 
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:
        "^[[Ps;Ps;Ps;Ps;PsT"
and scroll-down is:
        "^[[PsT"

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.
Comment 12 Hans de Goede 2004-11-12 06:33:08 UTC 
I still get the warning with 0.11.11-13
Comment 13 Ray Strode [halfline] 2004-11-12 13:18:27 UTC 
Hi,
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.
Comment 14 Ray Strode [halfline] 2005-02-16 16:17:29 UTC 
This was fixed a while ago, closing...
Comment 15 Kasper Dupont 2005-05-12 07:09:05 UTC 
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?
Comment 16 John Thacker 2006-10-31 20:55:28 UTC 
*** Bug 141324 has been marked as a duplicate of this bug. ***
Note You need to log in before you can comment on or make changes to this bug.