Bug 139294
Summary: | Mutt rendering problems in gnome-terminal | ||
---|---|---|---|
Product: | [Fedora] Fedora | Reporter: | Emmanuel Seyman <emmanuel> |
Component: | vte | Assignee: | Behdad Esfahbod <behdad> |
Status: | CLOSED CURRENTRELEASE | QA Contact: | |
Severity: | medium | Docs Contact: | |
Priority: | medium | ||
Version: | 3 | CC: | alanh, bbaetz, bloch, hdegoede, james, jmeehan-fedora, mattdm, poptix, redhat-bugzilla |
Target Milestone: | --- | ||
Target Release: | --- | ||
Hardware: | All | ||
OS: | Linux | ||
URL: | http://www.ediciel.com/~seyman/Capture.png | ||
Whiteboard: | |||
Fixed In Version: | 0.12.2 | Doc Type: | Bug Fix |
Doc Text: | Story Points: | --- | |
Clone Of: | Environment: | ||
Last Closed: | 2006-07-10 21:26:58 UTC | Type: | --- |
Regression: | --- | Mount Type: | --- |
Documentation: | --- | CRM: | |
Verified Versions: | Category: | --- | |
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
Cloudforms Team: | --- | Target Upstream Version: | |
Embargoed: |
Description
Emmanuel Seyman
2004-11-15 00:06:01 UTC
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 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. 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: 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 . 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: 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. *** 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 gnome-terminal. 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 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/ 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 issue. 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: 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. 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. Thank you! I haven't seen this on FC5 with all updates applied. Closing. |