lynx-dev
[Top][All Lists]
Advanced

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

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


From: Klaus Weide
Subject: Re: lynx-dev What's with the ncurses colors?
Date: Fri, 29 Oct 1999 21:18:11 -0500 (CDT)

On Fri, 29 Oct 1999, T.E.Dickey wrote:

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

I agree that the "linux" ncv should have bit 1 (underline) set - no
argument.

It probably also should have bit 4 (dim) set.  Both are simulated as
colors (overriding fg color as set by CSI 3x m completely), there isn't
a pricipal difference.  (uust that dim isn't much used in practice)

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

It also seems to be the part that doesn't get re-initialized when
one does <LYNXCFG://reload/>.

I still kinda like it, got used to it.  And it's limited to two
COLORs.  With the linux console I can change the appearence of
#     4 - underline                   - text emphasis (EM, I, B tags etc.)
#     5 - bold + underline            - hyperlinks within text emphasis
at runtime (without changes to lynx.cfg or terminfo), by doing

   ^Z
   setterm -ulcolor bright magenta
   fg

if I feel like it.

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

I think the adding-in of bold wasn't always there; it was "closer" then.

> > Does anyone disagree with, for curses-lynx in color mode, 
> 
> well, it's an odd color scheme, but I've gotten used to it.

But you can change the *scheme* (which colors for which of the given
purposes) as you like (nearly).  Taking out the always-bold for
COLORs 1,3,5,7 would bring lynx-ncurses closer in that regard.


   Klaus


reply via email to

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