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) 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.
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. Thanks!
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.
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 `initiate-hilite-mouse-tracking' defined.
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.
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.
I still get the warning with 0.11.11-13
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.
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. ***