junk in remote mutt

[Chad Perrin]

On Tue, Mar 18, 2008 at 07:23:43AM +0300, Yuri Pankov wrote:
> On Mon, Mar 17, 2008 at 04:03:54PM -0600, Chad Perrin wrote:
> > I'm not sure that's a very good title for this email, but it's what I've
> > got.
> > 
> > Since configuring my environment to use UTF-8, I've had a problem while
> > checking email on a server.  I log into the server via SSH, then enter
> > the `mutt` command.  As I page through the inbox, open and close emails,
> > et cetera, I get a bunch of junk on the screen -- characters from the
> > previous screen appearing on the current screen.  I have to use Ctrl + L
> > to clear it up and return the appearance of the screen to the way it's
> > supposed to look.
> > 
> > What can I do to eliminate this problem?  I don't want to have to force a
> > screen redraw every time I switch between views, scroll down a page in
> > mutt, and so on.  I also don't want to go back to a character set limited
> > to plain ol' ASCII (there's a reason I use rxvt-unicode instead of rxvt).
> 
> Don't see it here. If you are sure that mutt uses UTF-8 charset (ie,
> forced it with 'set charset="utf-8"'), make sure it's linked against
> ncursesw library (and not just ncurses) - need to use WITH_NCURSES_PORT
> on 6.2 and earlier or build it using WITH_SLANG.

I finally got around to checking the settings in the Makefile and
recompiling mutt.  End result: same problem.  If anyone else has any
ideas what might be causing this problem, please let me know.

addendum: The computer I'm using as a client to access mutt on another
machine doesn't have this same problem locally.  When I open a local mutt
instance, there's no junk on the screen.  I decided to try using SSH
through the remote system where I'm encountering this issue, then from
there using SSH to get back to the local machine, and opened mutt inside
this contrived SSH loop.  Still no problem.  Thus, whatever the problem
is seems to be particular to the remote machine.

I'm going to poke around some more and see if I can figure out what's up
while I wait for a response from anyone else who might have something to
offer, now that I've confirmed it seems to be specific to that machine.
Hopefully it's not related to the fact that the remote system is running
6.1-RELEASE while the system I'm using as a client is running
6.2-RELEASE, since that would pretty much mean I'm stuck with the
problem for quite some time (no desire to upgrade the FreeBSD version
number on the server).

-- 
CCD CopyWrite Chad Perrin [ http://ccd.apotheon.org ]
They always say that when life gives you lemons you should make lemonade. 
I always wonder -- isn't the lemonade going to suck if life doesn't give
you any sugar?