[Top][All Lists]

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

Re: lynx-dev What's with the ncurses colors?

From: T.E.Dickey
Subject: Re: lynx-dev What's with the ncurses colors?
Date: Fri, 29 Oct 1999 21:22:42 -0400 (EDT)

> 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; 
>         } 

actually, now it's implemented in ncurses, but in the meantime I verified
that SVr4 doesn't compensate for no_color_video.  It's been a while - a year
or so since I implemented that.
>         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? 

standout often has bold mixed with it in descriptions - that's why I
used 33.

                   Bit       Decimal
     Attribute     Position  Value

     A_STANDOUT    0         1
     A_UNDERLINE   1         2
     A_REVERSE     2         4
     A_BLINK       3         8
     A_DIM         4         16
     A_BOLD        5         32
     A_INVIS       6         64
     A_PROTECT     7         128

> 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. 

I've set ncv for a half-dozen terminal types based on testing with the
ncurses 'b' screen, to see which combinations work.  All it amounts to
is a statement that the terminal cannot combine those attributes with
color (it doesn't say _what_ the terminal will do, and I've seen some
terminals use the video attributes rather than color, and the opposite -
making ncurses handle it consistently imho is better than ignoring 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 

yes - hardcoded (and hard to find in the source, since part of it's buried
away in slang as a side-effect)

> 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) 

it was close - except for (iirc) a place where the slang library ignored the
calls from lynx to manipulate underline.  When I got down to that point, I
stopped working on it (no point in duplicating a bug).
>  * 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, 

well, it's an odd color scheme, but I've gotten used to it.

>  (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 

Thomas E. Dickey

reply via email to

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