Re: 256 colors
On Thu, Aug 31, 2006 at 08:50:25AM EDT, Alain Bench wrote:
> On Thursday, August 31, 2006 at 0:01:57 -0400, cga2000 wrote:
Apologies for not replying earlier.
> More precisely Screen reads the TERM=xterm (or whatever) terminfo
> for the real underlying terminal on one side, and implements a mostly
> hardcoded virtual terminal on the other side. Apps inside Screen run in
> this virtual term, and need an appropriate terminfo describing it:
> TERM=screen and friends.
>
> >>| screen-256color-bce|GNU Screen with 256 colors and BCE,
> >>| sgr0=\E[m^O,
> >>| ccc@, initc@,
> >>| use=xterm+256color,
> >>| use=screen-bce,
> > I understand that:
>
> Reverse: Values declared first win.
What confused me was that in that event the "use=" statements should
reflect the order of the successive layers in my "stack" .. IOW, the
xterm being at the bottom, the "use=screen-bce" should come before the
"use=xterm" .. I'm still unclear as to why this should not be.
> Note that a "+" in entry name denotes a building block, not a full
> usable entry.
I copied/pasted the above with "use=xterm+256color" and tic replied with
an "xterm+256color" terminfo not found .. or something to this effect.
So I had to change that to "use=xterm-256color" to match the actual
terminfo entry on my system.
Would this mean that my version of the terminfo package is ancient and
does not support this syntax?
> So this screen-256color-bce is: screen-bce, with added
> 256 colors definitions (colors#, pairs#, setaf/setab, ccc, and initc),
> wiped ccc and initc (customizing color palette is not implemented by
> Screen), and finally modified attributes-off to also turn off line
> drawing characters.
> > It looks like mutt is aware of certain 256-capable terminals based on
> > their terminfo name.
>
> Not on the entry name itself. Mutt and all well written apps should
> be checking the corresponding terminfo content:
>
> | $ tput colors
> | 256
This sure comes in handy..!
My current setup is entirely based on trial and error and I was rather
shocked to discover that issuing this command both in my underlying
xterm and in a gnu/screen + bash returned "8".
> But of course poorly written apps do exist. And also some apps may
> have user settings to override a presumed wrong terminfo.
Yes, I do force the colors to 256 in my .vimrc. And that Vim should be
able to display 256 colors makes some sense (?) since the underlying
xterm and gnu/screen are 256-color capable. IOW, the terminal has the
capability .. it's just my terminfo entry that does not correctly
advertise it.
> > screen-bce supports 256 colors
>
> No:
>
> | $ TERM=screen-bce tput colors
> | 8
What is not so clear is that although neither screen-bce nor the
terminfo I am using (plain TERM=xterm) specify 256 colors .. I do have
the following in my .screenrc:
| termcapinfo xterm 'Co#256:AB=\E[48;5;%dm:AF=\E[38;5;%dm'
My "understanding" .. can't think of a better word.. :-) was that this
would add 256-color capability to my plain xterm/screen-bce terminals.
As far as I can recall, I started off using TERM=xterm-256color and let
gnu/screen use its default terminfo entry (TERM=screen, I believe..)
I think that this worked as far as colors were concerned .. I was able
to get Vim and ELinks to display 256 colors. Not in a very elegant way
I must admit (see above).
But this introduced an annoying problem where things like the display of
the mutt status bar .. for instance .. was not rendered correctly. What
happened was that the background color of the status bar or the mutt
"indicator" would only materialize as long as there was some foreground
text .. instead of providing a continuous status bar or indicator bar
covering the entire width of the screen.
I did some googling .. and a bit of experimenting .. and I think that I
eventually fixed this by adding the following to my .screenrc:
| defbce on
Today, I did the following:
1. I followed your instructions and created the screen-256color-bce
terminfo entry .. changing xterm+256color to xterm-256color in order
to get it to compile without errors (see above)
2. I commented out the termcapinfo statement from my .screenrc
3. I added a "term screen-256color-bce" statement to my .screenrc
Then, I fired up a gnu/screen session making sure the underlying xterm
was using TERM=xterm-256color .. and I verified in a shell that
gnu/screen was using the new terminfo entry .. and hooray.. mutt
now recognizes my terminal's color capability...!!
Here's a screenshot of a draft version of my "256gold" color theme
based on the Vim theme that I currently use.
http://www.geocities.com/cga9999/m00.png
As you can see the "indicator" line in the index is "interrupted" after
the "h" of Bench and only resumes when further foreground text is
provided -- (59) .. etc.
.. and this in spite of the "defbce on" in my .screenrc.
So I got 256 color support in mutt to work but I'm back with my other
problem. Does this mean that you can only get this background color
thing to work when you limit yourself to the 8/16 basic colors?
> But whatever entry, your specially compiled Screen really supports
> 256 colors. Even if some apps already use them (by whatever trick), you
> still want a colors#256 entry to properly describe it.
Yes .. cleaning up my setup is a priority. I'm sure any upgrade will
likely break what's currently working.
> The pity in Mutt is the poor support of bright colors in 16 colors
> terminals. It does the same as in 8 colors mode: bold normal color.
Well.. unless they are really tight on RAM .. does anyone who sticks
with 8/16 colors in this day and age deserve our "pity".. ?
:-)
Seriously .. I think it's a shame non-GUI screen-mode apps such as Vim
.. mutt .. various browsers such as Elinks .. (and xterm and screen,
obviously..) do not support 256 colors out of the box.
I don't suppose that there is documentation anywhere that provides a
description of terminfo in a language that a curious layman such as
myself can understand. I've tried reading the man page several times
but unfortunately I cannot make any sense of it .. every other word is
a riddle and I don't know where to look them up.
Thank you very much indeed for your help.
I would be extremely grateful if you had any suggestions as to how I
might be able to solve this bce / garbled status line issue.
Thanks
cga