Re: Display problem
- To: mutt-users@xxxxxxxx
- Subject: Re: Display problem
- From: Kyle Wheeler <kyle-mutt@xxxxxxxxxxxxxx>
- Date: Wed, 28 Nov 2007 03:52:43 -0600
- Comment: DomainKeys? See http://domainkeys.sourceforge.net/
- Dkim-signature: v=1; a=rsa-sha1; c=relaxed; d=memoryhole.net; h=date:from:to:subject:message-id:references:mime-version:content-type:in-reply-to; q=dns/txt; s=default; bh=j8GW0CJt7/rqwyBdF5WE58855M8=; b=XP9gLlqJFrGkKrLLCtV5c9P23Kp0kb+W256sZkHNjbQY6yE6+B6CYCcJNkU/scJ6LU1LGNsYNblauLkN97etfSoAfiGAYE+QeIWcQMUeWvwUn9qvgl85TrAtp9QLpWB4wQ8KF8qxj/iKPIy1iaLQifErz1vntt1oEX+UcAVvKSU=
- Domainkey-signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=memoryhole.net; b=QZNs4IJjX0qc+E7mMIfnT7DgoyjlLHePOHjxxA8YJVc4jiBxk9wIUAVOPSCgYTsdWklpv9YipOZhsBn6H7+1sffhvLt6cQhfrDR593c7zQ424fWMABZQyBJJ0Rx0ZXc2ZDBdOEREe+rqJA9uQYNKM7R8qLUNY9MSIOkFPjuflWQ=; h=Received:Received:Date:From:To:Subject:Message-ID:Mail-Followup-To:References:MIME-Version:Content-Type:Content-Disposition:In-Reply-To:User-Agent;
- In-reply-to: <20071128090543.GA5779@xxxxxxxxxx>
- List-post: <mailto:mutt-users@mutt.org>
- List-unsubscribe: send mail to majordomo@mutt.org, body only "unsubscribe mutt-users"
- Mail-followup-to: mutt-users@xxxxxxxx
- References: <20071126141012.GA13425@xxxxxxxxxx> <20071126153445.GA10584@xxxxxxxxxxxxx> <20071128090543.GA5779@xxxxxxxxxx>
- Sender: owner-mutt-users@xxxxxxxx
- User-agent: Mutt/1.5.17 (2007-11-21)
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Well, the thing we're aiming for is to find a way to get all of your
various software pieces to agree on a configuration that works. This
is made more difficult by several things. It probably helps if you
think of the layers that you're working with here.
When mutt wishes to display something, it uses ncurses (or slang,
depending on how you've compiled mutt). Ncurses must then send the
sequence of bytes necessary to display what mutt wants to the
terminal. Since there is no terminal, ssh intercepts this output, and
forwards it to your remote application.
Each terminal (application) has different capabilities (such as being
able to draw lines or being able to draw colors or scroll portions of
the terminal or what have you), and different byte sequences for
telling it to do these things. This is why we have ncurses (and
slang): so that mutt doesn't need to know about every dang terminal in
existence. Unfortunately, that means that ncurses must know about
every dang terminal in existence, or at least, it must know about the
terminal that *you're* using (and the only way it knows this is from
the TERM setting). People writing new terminal applications (e.g.
putty) know this, and while they like adding features, generally they
want their terminal to work sooner than later, so they tend to emulate
older terminals (e.g. xterm). Now, throw into this mix possibly buggy
ncurses terminal definitions (it happens), buggy terminals, buggy
emulations... Oh, and just for grins, let's also throw in the
possibility (nay, likelihood) of fonts that don't support all the
necessary characters, and it can get darn hard to figure out why
something doesn't display properly! :)
On Wednesday, November 28 at 10:05 AM, quoth Steve:
>> Now, I *think* (and you'd have to dig into the Konsole
>> documentation) that the correct TERM setting for it is
>> "xterm-color" (because it's emulating an xterm), though there may
>> be a more accurate setting (check the Konsole docs).
>
> I tried to
>
> export TERM=xterm-color
>
> but the problem arised again.
Well, then, chances are xterm-color isn't correct for your version of
Konsole. Hmm. Try export TERM=kterm, maybe that'll work. Or even
TERM=konsole. Konsole may have configurable emulation modes... I don't
use it, so I'll let you investigate.
>> The correct setting for when you're using putty depends on what
>> putty is emulating; check into putty's configuration, and set it to
>> something useful. It's probably emulating a VT100 terminal, and you
>> want it to emulate something a little more capable, like an xterm.
>
> In putty, Connection -> Data is currently set to xterm. I tried several
> different values found in the litterature (uxterm, putty, linuxi ..) and
> still the same problem..
Changing the setting in Connection->Data only changes what PuTTy
*claims* to be, not what it actually behaves like (don't you love how
those are separate settings?). For example, in Window->Translation,
you can adjust how Putty handles line-drawing characters, in
Window->Colours you get to change whether it supports 256 colors or
not, and so forth. Whatever you do, you need to alter your TERM
variable to reflect whatever it is that you've told Putty to behave
like (e.g. if you've told it to behave just like xterm with 256 color
support, TERM should be xterm-256color (or a subset of that, such as
xterm-16color)). TERM doesn't change just because PuTTy changes how it
operates, it is (unfortunately) manual.
In some cases, depending on your version of ncurses, I've heard that
setting TERM to putty-vt100, putty, or putty-256color (in ascending
order of complexity (i.e. if putty doesn't work, then putty-vt100
might work, but if 'putty' doesn't work at all, putty-256color is
unlikely to work)).
Unfortunately, because what terminals are supported by ncurses depends
heavily on your particular version, and how a terminal (mis)behaves is
also dependent on the version of the terminal, I can't give you a 100%
guaranteed answer. But I say play around with your TERM setting and
see if you can't get one that behaves itself.
>> Setting your TERM variable depends on what shell you're using, but to
>> test the setting regardless of shell, use this:
>>
>> env TERM=xterm mutt
>
> Also tried this and .. shoul I precise?
I don't understand the question.
Hope that helps,
~Kyle
- --
You never truly understand a thing until you can explain it to your
grandmother.
-- Albert Einstein
-----BEGIN PGP SIGNATURE-----
Comment: Thank you for using encryption!
iD8DBQFHTTprBkIOoMqOI14RAnW8AKDR3M0KetbGOMi+de5NmV8Sk+C3kQCeIHpm
7iLI5gfiMIWyTUhTsX6LTWk=
=y3r6
-----END PGP SIGNATURE-----