Bug 139294 - Mutt rendering problems in gnome-terminal
Summary: Mutt rendering problems in gnome-terminal
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: Fedora
Classification: Fedora
Component: vte
Version: 3
Hardware: All
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Behdad Esfahbod
QA Contact:
URL: http://www.ediciel.com/~seyman/Captur...
Whiteboard:
: 141541 (view as bug list)
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2004-11-15 00:06 UTC by Emmanuel Seyman
Modified: 2007-11-30 22:10 UTC (History)
9 users (show)

Fixed In Version: 0.12.2
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2006-07-10 21:26:58 UTC
Type: ---
Embargoed:


Attachments (Terms of Use)

Description Emmanuel Seyman 2004-11-15 00:06:01 UTC
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):
mutt-1.4.1-10
vte-0.11.11-6
gnome-terminal-2.7.3-1

How reproducible:
Always

Steps to Reproduce:
1. Launch mutt in gnome-terminal
2. go to a mailbox containing several mails
3. scroll back and forth repeatingly
  
Actual results:
Lines of text persist between mails (see screenshot at URL)

Expected results:
screen should be cleaned between mails

Additional info:
Discussion on fedora-list:
http://www.redhat.com/archives/fedora-list/2004-November/msg02877.html

Comment 1 Alan Hourihane 2004-11-16 11:23:55 UTC
I'm seeing the same problem too.

Comment 2 Rocco Corsi 2004-11-21 20:40:33 UTC
Problem is also reproducible with GNU Nano and Gnome-Terminal.

1) Manually create a file that has this content

1 line
2 line
3 line
4 line
5 line
6 line
7 line
8 line
9 line
0 line

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.

5) CTRL-k

6) CTRL-u a few times

7) Scroll up with CTRL-y, some lines will have a number, but not the
word "line".

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
is wrong.

Comment 3 Paul Tomblin 2004-11-24 00:45:29 UTC
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".


Comment 4 Adam Huffman 2004-12-14 22:48:45 UTC
I've tried Paul Tomblin's workaround and that has stopped the
corruption for me.

Comment 5 Adam Huffman 2004-12-16 21:48:05 UTC
Unfortunately, that breaks the Home and End keys in mutt.

Comment 6 Matthew S. Hallacy 2004-12-21 16:48:36 UTC
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.

Comment 7 Emmanuel Seyman 2004-12-21 21:46:16 UTC
Apologies, I've put a screenshot back:
http://lasker.ediciel.com/~seyman/Capture.png

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 .

Comment 8 Matthew S. Hallacy 2004-12-21 23:49:47 UTC
This bug is a duplicate of Bug #141541 which has more information
about the actual problem.

Comment 9 Chris Runge 2005-01-11 17:35:48 UTC
I'm also seeing this with RHEL 4 betas using the following packages:

gnome-terminal-2.7.3-1
mutt-1.4.1-10
ncurses-5.4-13

Running mutt in an xterm does not have this problem.

Comment 10 Petr Rockai 2005-02-17 14:29:34 UTC
*** Bug 141541 has been marked as a duplicate of this bug. ***

Comment 11 Hans de Goede 2005-02-23 16:03:51 UTC
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
gnome-terminal.


Comment 12 John Thacker 2005-03-03 17:39:32 UTC
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
as RAWHIDE

Comment 13 Emmanuel Seyman 2005-03-08 21:30:32 UTC
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.

http://people.redhat.com/wtogami/temp/vte-FC3/
http://people.redhat.com/wtogami/temp/vte-FC4/


Comment 14 Adam Huffman 2005-03-09 21:48:32 UTC
While those packages are a vast improvement, they don't fix the mutt rendering
problem completely, especially under screen.

Comment 15 Hans de Goede 2005-03-10 08:48:20 UTC
AFAIK screen sets TERM=screen, so this is might not be gnome-terminal
related, does mut work correctly with screen under a real xterm?


Comment 16 Emmanuel Seyman 2005-03-10 09:31:06 UTC
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
issue.

Adam, can you give us a minimal test case?

Comment 17 Adam Huffman 2005-03-10 11:37:16 UTC
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.

Comment 18 Jim Meehan 2005-04-17 01:40:59 UTC
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:

http://vpizza.org/~jmeehan/mutt-problem.pdf

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.

Comment 19 Hans de Goede 2005-04-17 06:12:41 UTC
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.


Comment 20 John Thacker 2005-04-17 15:37:07 UTC
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.

Comment 21 Matthew Miller 2006-07-10 20:53:22 UTC
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.

Thank you!


Comment 22 Emmanuel Seyman 2006-07-10 21:26:58 UTC
I haven't seen this on FC5 with all updates applied. Closing.


Note You need to log in before you can comment on or make changes to this bug.