Red Hat Bugzilla – Bug 139294
Mutt rendering problems in gnome-terminal
Last modified: 2007-11-30 17:10:54 EST
Description of problem:
Soon after installing FC3, I noticed rendering problems in mutt using
gnome-terminal. Scrolling rapidly from mail to mail leaves lines
sticking after they should have been cleaned off the screen.
Pressing Ctrl-L cleans the screen.
This problem doesn't manifest using other terminals or with a TERM
variable containing linux or gnome.
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1. Launch mutt in gnome-terminal
2. go to a mailbox containing several mails
3. scroll back and forth repeatingly
Lines of text persist between mails (see screenshot at URL)
screen should be cleaned between mails
Discussion on fedora-list:
I'm seeing the same problem too.
Problem is also reproducible with GNU Nano and Gnome-Terminal.
1) Manually create a file that has this content
2) then move to the "1 line"
3) set the mark (i.e CTRL-^)
4) move to the line just after "0 line", basically marking everything.
6) CTRL-u a few times
7) Scroll up with CTRL-y, some lines will have a number, but not the
8) Scroll up and Scroll down several times and see the strange output.
Try different things with scrolling and moving around with cursor keys.
9) You can also hit CTRL-l to update the screen to show that something
The bug is not in the rendering. If anything, it's either in the
terminfo database or in ncurses. I can reproduce the problem with
mutt (and trn) ssh'ed in from an Macintosh computer. Since it's the
Macintosh Terminal program doing the rendering, not Gnome-Terminal, it
can't be Gnome-Terminal's fault.
BTW: I never had this problem with the Mutt that came with RedHat 9
ssh'ed in from the same Macintoshes. Also, doing a "TERM=linux mutt"
makes the problem go away. Normally when sshed in, $TERM is "xterm".
I've tried Paul Tomblin's workaround and that has stopped the
corruption for me.
Unfortunately, that breaks the Home and End keys in mutt.
It seems that the screenshot was removed from the url above, can
anyone verify that this is not a unicode issue? mutt is unicode
capable and will display double width characters (usually seen in
spam) which causes non-compliant terminals to line-wrap the end of the
line in mutt, causing a "space" issue.
If anyone else can present a screenshot, and 'echo $TERM' I would be
happy to investigate.
Apologies, I've put a screenshot back:
Here, the TERM value is "xterm" . Changing this to "linux"
make the problem go away.
I really don't think it's an Unicode problem.
Rendering was perfect in RHL 9, FC 1 & 2 .
This bug is a duplicate of Bug #141541 which has more information
about the actual problem.
I'm also seeing this with RHEL 4 betas using the following packages:
Running mutt in an xterm does not have this problem.
*** Bug 141541 has been marked as a duplicate of this bug. ***
This has been discussed in bug 122815 and is caused by a newer xterm
terminfo entry which contains the indn and rin capabilities, deleting
these from the xterm terminfo entry will probably fix this, but I
thought that this was also supposed to be fixed in/by a newer
This is fixed (for me) in rawhide with at least the vte-0.11.11-15 package, and
possibly earlier. Possibly also related to bug 134300. I can't view bug
128375, which seems like it's related as well.
Anyway, people who want this fixed, update vte from rawhide. Recommend closing
I tried updating vte to Rawhide. Rendering is much better but not perfect.
Warren Togami posted rpms of vte 0.11.12. I've been trying this one for a few
hours and it does look as if this one fixes the bug.
While those packages are a vast improvement, they don't fix the mutt rendering
problem completely, especially under screen.
AFAIK screen sets TERM=screen, so this is might not be gnome-terminal
related, does mut work correctly with screen under a real xterm?
I noticed speed issues running mutt in a screen session but chalked it down to
network lag (I only use screen when I ssh into a box). Running with "screen -T
gnome mutt" doesn't change much, if anything so I'm not convinced this is a vte
Adam, can you give us a minimal test case?
Emmanuel - I think it may be a problem in ncurses and/or terminfo, see comments
3 and 11. I will try and provide the screen test case this evening. However,
when connecting directly to a machine running the new vte (i.e. not using
screen), from an FC2 machine, I see the same screen corruption problems in mutt.
I'm also seeing some corruption problems with mutt. SSH'ing into a stock FC3
machine and running mutt under screen. When I scroll through a message list
page by page using right/left-arrow, the status line gets overwritten, and lots
of other lines aren't updated. Screen shot here:
My local client is Mac OS 10.3, running ssh under Terminal.app. But I get the
exact same problem/results using PuTTY on a Windows machine. I've tried
TERM=xterm, TERM=linux, etc. All with the same results.
This bug has a component of vte (gnome-terminal rendering lib) and the summary
says rendering problems. So people please see if you can report this with the
latest ncurses and vte from rawhide running mutt under plain gnome-terminal.
So no reports about:
-running under screen
-running under max os x terminal app (bug apple)
All these relelated issues should go in seperate bug reports.
The problems with logging in from FC2 to FC3 still occur with an updated vte,
but isn't that because you're running gnome-terminal with the old vte (but using
the new termcap/terminfo files on the FC3 machine)? I don't think that could be
fixed without updating vte on FC2 as well.
Fedora Core 3 is now maintained by the Fedora Legacy project for security
updates only. If this problem is a security issue, please reopen and
reassign to the Fedora Legacy product. If it is not a security issue and
hasn't been resolved in the current FC5 updates or in the FC6 test
release, reopen and change the version to match.
I haven't seen this on FC5 with all updates applied. Closing.