Re: lynx-dev Lynx vs. color-pairs?

[Bela Lubkin]

Thomas Dickey wrote:

> On Thu, Sep 12, 2002 at 08:00:29PM -0700, Bela Lubkin wrote:
> > I'm trying to understand some odd Lynx output with SCO OpenServer curses
> > and the "ansi" terminfo entry.  The entry reads:
> > 
> > =============================================================================
> > #   Reconstructed via infocmp from file: /usr/lib/terminfo/a/ansi
> > ansi|ansic|ansi-437|ansi80x25|Ansi standard console,
> >     am, bce, eo, xon,
> >     colors#8, cols#80, it#8, lines#25, pairs#64,
> ...
> >     op=\E[37;40m, rev=\E[7m, ri=\E[T, rmacs=\E[10m,
> >     rmso=\E[m, rmul=\E[m, setb=\E[4%p1%dm,
> >     setf=\E[3%p1%dm, sgr0=\E[10;0m, smacs=\E[12m,
> >     smso=\E[7m, smul=\E[4m,
> > =============================================================================
> > 
> > With this entry, Lynx outputs what appears to be an entire screen's
> > worth of blank spaces at startup.  It also outputs big wads of spaces at
> > other times.
> 
> It shouldn't.  The 'bce' is a hint to curses that clearing (generally
> ED erase-display and EL erase-line) retains the current colors.

So if you do wbkgd() followed by an immediate refresh, it _should_ be
smart enough to know that a ED would do the trick.  But the code for
that smarts could easily be missing.  Seems like it would either have to
set a flag indicating a pending ED (with whatever colors were in effect
at the time), or the refresh code would have to scan the entire window
buffer for identical chars, count them up, and decide whether a bulk
erasure was the best way to get the desired contents.  In any case, it
isn't happening that way...

> > An entry that reads "ansi-nopairs|testing, pairs@, use=ansi," eliminates
> > this extra output.  So the problem is somehow related to "pairs=64".
> > 
> > In fact, it seems to happen with any value of "pairs" larger than 8.
> > Also, arbitrarily adding "pairs#9" to any other random terminfo entry
> > causes the same behavior.
> 
> That's odd.  I don't think I've seen Solaris curses do this, but have
> noticed that dtterm's 'pairs' value is given as 8, which doesn't reflect
> the emulator's capabilities.  (In ncurses we changed it to 64).
> It's possible that is related - that someone found it didn't work well
> for some flavor of curses.
>  
> > I think this is related to this macro in LYCurses.c:
> > 
> >   #define COLOR_BKGD ((COLOR_PAIRS >= 9) ? COLOR_PAIR(9) : A_NORMAL)
> 
> Possibly.  The '9' here is related to the way lynx builds color pairs.

My thought was that if I changed this to `(COLOR_PAIRS >= 4)', for
instance, then this would happen with pairs#5.  That is, for whatever
reason, my curses library does something stupid if you call wbkgd(...
COLOR_PAIR()), but does OK if you call wbkgd(... A_NORMAL).

> See this chunk around line 650 in lynx_map_color:
> 
>     lynx_color_pairs[n+1].fg = lynx_color_cfg[n].fg;
>     lynx_color_pairs[n+1].bg = lynx_color_cfg[n].bg;
> 
>     lynx_color_pairs[n+9].fg = lynx_color_cfg[n].fg;
>     lynx_color_pairs[n+9].bg = lynx_color_cfg[0].bg;
> 
>     lynx_color_pairs[n+17].fg = lynx_color_cfg[n].bg;
>     lynx_color_pairs[n+17].bg = lynx_color_cfg[n].bg;
> 
> It looks odd, but the intent was to make the colors behave the same way in
> curses as in slang.

I won't pretend to understand it...

> > and the calls to:
> > 
> >   wbkgd(LYwin, COLOR_BKGD | ' ');
> 
> I guess you're talking about the space (' ').  If I don't add that, then
> Solaris tends to eliminate the corresponding cells (sends a null).  I don't
> recall looking to see what OpenServer did in this case.  At the time I was
> debugging this, of course, I was testing Solaris on a dialin, and could
> also see the effect of a mismatched 'bce' quite easily.  Now I tend to use
> 'script' to see what's going on.

No, it seems to be sensitive to what color/attribute you attach.

I've been using `script` to see what's going on; or, more crudely, `wc`.
Just simply running `TERM=whatever lynx | wc` and hitting ^D gets me a
pretty good measure of what's going on -- it's about 1600 chars with a
happy terminfo and ~7000 with one that causes massive space spewing.

> > in lynx_map_color() and lynx_init_colors().  In fact I think I could
> > kludge a "fix" in several different ways... what I don't know is how to
> > fix it _right_.  I figure Tom will know, since he maintains both Lynx
> > and the main implementation of curses...
> > 
> > The right answer might be "OpenServer curses' wbkgd() is busted, it
> > should know to emit ESC[2J to `clear' the screen to a particular color
> > set rather than painting it with spaces".  But I hope not, that'll be a
> > pain to fix...
> 
> But without wbkgd, things don't look very good, either.

No doubt.

> > Lynx is:
> > 
> >   $ lynx -version
> >   Lynx Version 2.8.5dev.8 (28 May 2002)
> >   libwww-FM 2.14, SSL-MM 1.4.1, OpenSSL 0.9.6b
> >   Built on sco3.2v5.0.7 Jul 25 2002 03:57:05
> 
> I still have the 5.0.5 for testing (and the sdk from, I guess, Unixware).
> So it's possible for me to do some comparisons.

Well, the UnixWare SDK would have you using the UnixWare curses library,
which is related but not identical.  And it probably opens terminfo
entries from some other database directory.  So, not sure how close that
would get you to the problem.

Other avenues might be to fiddle the wbkgd() calls to ask for weird
colors, see if that provokes any misbehavior with other curses packages
(but probably won't, I'm sure that one component of this is odd/bad
behavior in the OpenServer curses library -- I just need to characterize
_what_).

I can get you an account on an accessible system running 5.0.6 (most
current shipping release) with up-to-date patches, native devsys, etc.
Send private reply.

>Bela<

PS: I also just realized that I should have said I was building with
color styles disabled; probably obvious from the rest of the discussion,
but now it's definitive.

; To UNSUBSCRIBE: Send "unsubscribe lynx-dev" to address@hidden