Red Hat Bugzilla – Bug 155153
rendering problems when running mutt under screen
Last modified: 2007-11-30 17:11:04 EST
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.7.6) Gecko/20050317 Firefox/1.0.2
Description of problem:
Having some garbled text problems when running mutt under screen. This is on
a remote FC3 server that lives in a colo facility. When I use right-arrow
or left-arrow to scroll through a list of messages, the mutt status line gets
overwritten, some text lines don't get updated, etc. The problem is especially
bad when viewing my spam/junkmail folder where there are lots of messages with
subject lines in unicode/utf-8, etc.
Hitting ^L to redraw the screen does clear up the problem (mostly).
There are still a few out-of-place characters even after ^L when viewing
my spam folder.
I've tried ssh'ing in from Terminal.app in Mac OS X, and PuTTY in Windows -- problem is the same with both.
If I run mutt by itself, without starting screen first, it seems to be
mostly okay. Still a few rendering problems in my spam folder.
I see there's a bugzilla bug #139294 open for a similar problem, with mutt
running under gnome-terminal. Maybe related?
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1. ssh into FC3 machine
2. start screen
3. start mutt
4. go to a folder with several pages of messages
5. scroll through message listing using right/left arrow keys
Actual Results: mutt status line overwritten, text snippets from other pages of messages not cleared from screen, etc.
Expected Results: message list should be displayed correctly, status line should remain intact
screen shot of garbled mutt display:
This is a known problem with vte as shipped in FC3, and is the same as bug
#139294. It's been fixed in Rawhide (and the FC4 Test releases) for a while.
Even with the fixed vte, there are problems if you ssh from FC2 to FC3. But the
problems with screen, PuTTY, etc., are fixed.
Personally, pushing a fixed vte update out there might be a good idea. But
that's the package with the problem, not screen.
Please reopen with the right component if still relevant at all. The above
scenario works for me without problems, so definitely not screen's fault. I
suppose John is right here and the problem is (was) with vte...