[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
address@hidden
http://www.clark.net/pub/dickey