Le 28-11-2007, à 12:51:27 -0600, Kyle Wheeler (kyle-mutt@xxxxxxxxxxxxxx) a
écrit :
> Lignes : 114
>
> On Wednesday, November 28 at 11:33 AM, quoth Steve:
> > I haven't compiled mutt, but
> >
> > aptitude install mutt
> >
> > Here is the output of mutt -v :
> >
> > System: Linux 2.6.18-5-amd64 (x86_64) [using ncurses 5.5] [using
> > libidn 0.6.5 (compiled with 0.6.5)]
>
> Hmm, okay. Ubuntu, I'm guessing?
Naaah, Debian etch, of course ;-)
> >> 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.
> >
> > Which is either konsole or puTTy ?
>
> Right. Well, I was thinking PuTTy. In the case of Konsole, obviously
> ssh isn't involved.
>
> >> 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).
> >
> > ok but I'm not using any weird terminals, only well known ones.
>
> True, but that doesn't always mean bliss. :)
>
> > I'll try this as soon as I get out of mutt. What do you mean with
> > 'configurable emulation modes' ? I think I don't understand very
> > well what emulation' means ...
>
> Ah, well... so, since folks have begun to recognize that what we don't
> need is MORE unique terminals with their own reinvention of the "how
> to draw things to the terminal" wheel, most often newer terminals
> (e.g. Konsole) will accept the same commands as older terminals (e.g.
> xterm). When they do this it's called "emulation" for the simple
> reason that Konsole isn't actually an xterm, but rather it's just
> attempting to behave like one. The problem, however, is that it's
> usually an incomplete or inaccurate emulation, and it may behave
> *slightly* differently in *some* situations, which leads to problems
> for programs like mutt that really put terminals through their paces.
> And, unfortunately, this usually doesn't lead to the new terminals
> *correcting* their behavior, but more often it just leads to ncurses
> developing yet another terminal description to try and work
> with/around the weirdness.
Ok thanks for the explanation.
> Anyway, "configurable emulation modes" is when a terminal program
> gives you a choice of terminals to emulate. For example, it could ask
> "do you want me to behave like an xterm? or like a vt100 console? or
> like an rxvt terminal?" Different modes may be more or less accurate
> (and more or less complete), leading to some duplication of
> capability. In any case, whatever you tell your terminal to behave
> like, that's what you need to set in your TERM envariable.
>
> Make sense?
Yes, thanks.
> >>> 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?).
> >
> > Are you telling me that any settings in puTTy are useless or by any
> > means for my particular problem ?
>
> No... I'm telling you that settings in puTTy affect what TERM setting
> is most accurate.
>
> >> in Window->Colours you get to change whether it supports 256 colors
> >> or not, and so forth.
> >
> > Here I have (default values) :
> >
> > Allow terminal to specify ANSI colours
> > Allow terminal to use xterm 256-color mode
> > Bolded text is a different colour
>
> My point is that if you allow 256 colors, the most accurate TERM
> setting is 'xterm-256color' (or something along those lines), whereas
> if you didn't, the most accurate setting would be 'xterm' or maybe
> 'xterm-16color'.
ok. After reading all the documentation of puTTY, I fel on something
which might be interresting. From the doc :
4.12.2 ‘Allow terminal to use xterm 256-colour mode’
This option is enabled by default. If it is disabled, PuTTY will ignore
any control sequences sent by the server which use the extended
256-colour mode supported by recent versions of xterm.
If you have an application which is supposed to use 256-colour mode and
it isn't working, you may find you need to tell your server that your
terminal supports 256 colours. On Unix, you do this by ensuring that the
setting of TERM describes a 256-colour-capable terminal. You can check
this using a command such as infocmp:
$ infocmp | grep colors
colors#256, cols#80, it#8, lines#24, pairs#256,
If you do not see ‘colors#256’ in the output, you may need to
change your terminal setting. On modern Linux machines, you
could try ‘xterm-256color’.
So I tried this commande on my linux box :
infocmp | grep color
colors#8, cols#80, it#8, lines#24, pairs#64,
No "color256". Coulf this have an effect on my problem ?
> > Thanks a lot Kyle for your extended explanations. I'll play around
> > with the TERM variable and see if I have more success. I'll let you
> > know as I'll let the debian-user-french list know also since a lot
> > of people there are experiencing the same problem.
>
> Also try Gary's suggestion of running xterm instead of Konsole, just
> to see if you get the same display problems. If you don't, then that's
> useful information. If you get the same problems, that's also useful
> (and means we're trouble-shooting in the wrong direction).
I tried to run mutt in a xterm (locally) and I got exactly the same behaviour.
And now I'm really becoming completely confused (and a bit frustrated: I showed
mutt to a friend yesterday night, telling him that "All mail clients suck. This
one just sucks less." but this problem suddenly arised, all he said is "well
this one sucks too!"...
Thanks helping me.
Have a nice day,
Steve
> ~Kyle
> --
> It is said that power corrupts, but actually it's more true that power
> attracts the corruptible. The sane are usually attracted by other
> things than power.
> -- David Brin
>
Attachment:
signature.asc
Description: Digital signature