<<< Date Index >>>     <<< Thread Index >>>

Re: 256 colors



On Tue, Sep 12, 2006 at 09:45:14PM EDT, Henry Nelson wrote:
> On Sat, Sep 09, 2006 at 10:35:00AM -0400, cga2000 wrote:
> > happened .. To fix the "bce issue" I set TERM to terminfo entries that
> > were not 256-color capable on terminals (screen/xterm) that _did_ have
> > the capability ..  and then used the config files where possible (vim,
> > eg.) to inform the apps of the terminal's real color capabilities ..
> 
> Could you elaborate (explain with concrete examples) this section.  I
> don't really understand what the "bce issue" is, nor what "the config
> files" refer to.  TIA

The "bce issue" refers to a problem with stuff like status lines -- say
white text on a blue background..  What I have observed is that I
"lose" the background color .. or rather it stops where text stops.

Difficult to describe but you can check out the mutt screenshot I
posted recently for a sample.

This is somewhat annoying when for instance you are in the mutt index
with the "current message" highlighted..  When you move up and down the
index, the "indicator" line (? .. I think that's what it's called ..
no time to check ..) is broken somewhere in the middle and the two
separate parts of the line change lengths depending on the length of
the current message's subject for instance.

It's not only ugly but it also becomes rather annoying after a while.

:-)

I have no understanding of terminals in general and this particular
problem in particular.  So I cannot explain this further but for me at
least Alain B's terminfo took care of this problem.

And as they say the rest is history:

What happened was that I was never able to find a screen-256color entry
that did not cause the problem so I cheated to work around this problem
that affected all apps running under gnu/screen (256 color-capable or
not..) 

So what I did was to use a 256-color capable xterm (of that I am sure)
and I _think_ a 256-color capable version of screen.  Not sure of the
latter, I'd have to check.

But then I used plain TERM=xterm for my xterm (8 colors, I think..
certainly not 256) -- which is what screen "sees" when it starts up ..
and a TERM=screen-bce for screen (not 256-color capable either) because
this particular combination of terminfo entries did not cause what I
earlier nicknamed the "bce issue".

I then managed to get Vim and ELinks (again a 256-color capable version)
to use the 256 colors that my hardware was capable or (xterm configured
with 256 colors) by "saying so" in their respective config files.  And
both apps were kind enough to oblige.

mutt, OTOH only cares about what is specified in the terminfo entry
pointed to by the TERM env variable and stubbornly complained that my
terminal was not 256-color capable when I tried to issue commands like
":color ...  color123 .." eg.

I still have "defbce on" in my .screenrc but have not had time to test
whether it is necessary when running with Alain's terminfo entry. My
understanding is that it shouldn't and what's specified in the terminfo
entry should be sufficient (?)

I'm not sure this helps at all where you are concerned but it may
clarify my earlier posts (?)

> For the record, my scenerio is: Use Mutt and other apps within GNU
> Screen (--enable-colors256) on NetBSD server.  Shell is csh.  TERMCAP
> and TERMINFO (location of description databases) are set in .login,
> but TERM is not set.  The terminal emulation is PuTTY on WindowsXP,
> and PuTTY is set to pass "putty-256c" to the shell.  

I tried with putty (or rather pterm) before xterm -- I think because it
was the only 256-capable terminal emulator that was available in the
debian sarge repository.  I don't remember why I switched back to xterm
.. except that I pterm has a complicated configuration GUI and I had
enough on my plate without having to learn how to use it.

Also the xterm package provides a couple of scripts that let you
display the available colors and I don't think pterm has the equivalent.

> (The name of Alain's "putty-256color" was shortened in source file
> before tic'ing so that screen can be invoked within screen.)  `setenv
> | grep TERM` output is: "TERM=screen.putty-256c".  In $HOME/.screenrc
> I have "termcapinfo putty* vb@" and "termcapinfo putty* hs@" on
> separate lines.  I do not set "term" in $HOME/.screenrc.  (I used to,
> but it didn't seem to matter so I commented that line out.)
> 
> Other than not being able to print via vtprint or lpansi, the above
> setup seems to be working okay.  Nevertheless, any and all advice
> and/or suggestions very welcome and appreciated.

Sorry about not really being able to explain anything useful.  The most
I could do is probably to write down exactly what I did to get this to
work flawlessly in my own particular setup.  Probably would need to be
adapted for anyone using putty .. rxvt .. or other 256-capable terminals
if there are any currently available.

Thanks

cga