lynx-dev
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

lynx-dev What's with the ncurses colors?


From: Klaus Weide
Subject: lynx-dev What's with the ncurses colors?
Date: Fri, 29 Oct 1999 19:25:46 -0500 (CDT)

Another thing I found with ncurses and color (non-lss):

Some colors always get high intensity, whether I want it or not,
and there's no way to turn it off.

Specifically (although I haven't tested all cases through),
it's the odd-numbered COLORs that always get bold - the ones
that nominally coresspond to bold [ + something else ], according
to lynx.cfg.

For example, 

   COLOR:1:blue:white

becomes effectively

   COLOR:1:brightblue:white

(actually, the same as 'COLOR:1:brightblue:lightgray' but that doesn't
matter here - just the usual "background can have only one intensity"
limitation)

but

   COLOR:2:blue:white

*is* different from

   COLOR:1:brightblue:white .

This is caused by the first lines of: (LYsetWAttr in LYCurses.c)

        /*
         * no_color_video isn't implemented (97/4/14) in ncurses 4.1, but may
         * be in SVr4 (which would make this redundant for the latter).
         */
        if ((Current_Attr & A_BOLD) && !(NoColorVideo & 33)) {
                attr |= A_BOLD;
        }

        if ((Current_Attr == A_UNDERLINE) && !(NoColorVideo & 2)) {
                attr |= A_UNDERLINE;
        }

First, is that comment still correct?  ISTR it wasn't when I checked
ncurses source some time ago.

Also, if anything why test for 33 instead of just 32?

Third, was it really meant to be 'Current_Attr == A_UNDERLINE' rather
than 'Current_Attr & A_UNDERLINE'?  Below I assume the latter was
intended (because I wrote most of it before noticing the difference...)

Well, I found a way to work around this.  Actually, two ways:

- Use a terminfo description that does have bits 0 or 5 set in
  the ncv (in)capability.
  The "linux" description I have from ncurses 50 beta (990410) has
  ncv#2, I found various others (variants or older versions) with
  different or no ncv.

- Use the recently added -nobold flag.
  But this is not what I want - I want bold for *some* things.
  Well, I'm not yet sure I understand when -nobold comes into
  effect in color mode.  I suppresses high intensity even in
  an explicit 'COLOR:1:brightblue:white' but leaves the yellow
  of the statusline (in the default 'COLOR:2:brown:blue') as
  yellow and therefore high intensity.


So I can work around it, but I shouldn't have to.  I should get the
colors I specify.  An ncv with bit 5 set is not really a fitting
description for my console.  Moreover in practice very few people
would go to such lenghts as creating a variant terminfo file for this,
they would rather compile lynx with slang which doesn't have this
problem.

I thing it doesn't make sense to add in the "bold" bit for those
colors that somehow correspond to "bold [+ ...]", the boldness is
already spoken for by the color choice.

Doing the equivalent for "underline" (as also shown above) may
make somewhat more sense.  At least visual underlining is clearly
something different form a color change, so it may make sense
for terminals that really show underline as such.  (Not for my
linux console, but that is taken care of by ncv#2.)  But as far
as I'm concerned we could get rid of it too..

I am aware that slang does a similar thing wrt underline, but
only for COLORs 4 and 5, and then unconditionally (not honoring
ncv, last I checked).  I would ask to not modify the behavior
with slang though.  (Call me inconsistent, but I actually find
it useful; and it's been long-established lynx-with-slang practice.)

In my opinion, ncurses-(non-lss-)lynx still does not achieve what
it set out to do, "produce the same effects as slang": (from LYCurses.c)

 * This block of code is designed to produce the same color effects using SVr4
 * curses as the slang library's implementation in this module.  That maps the
 * SGR codes into a 0-7 index into the color table, with special treatment for
 * backgrounds.  There's a bit of convoluted (but necessary) code handling the
 * special case of initialization before 'initscr()' is called.
 * 1997/1/19 - T.E.Dickey <address@hidden>

It probably shouldn't try to mimick the slang behavior in all aspects
(like the underline peculiarity), but it should come closer; I think
slang-lynx is somewhat more popular and this is one of the reasons.

Does anyone disagree with, for curses-lynx in color mode,
 (a) getting rid of the added bold attributes for COLORs 1,3(unused),5,7?
 (b) not adding underline attributes for all of COLORs 4,5,6,7 (in
     case that was the intention)?
     [(b), as it is now, amounts to adding underline only for COLOR 4 -
      which I have no problem with, it is less than what is done with
      slang.]


   Klaus




reply via email to

[Prev in Thread] Current Thread [Next in Thread]