Re: LYNX-DEV highlighting bug in color slang version

[Laura Eaves]

> From: "T.E.Dickey" <address@hidden>
> Date: Fri, 11 Apr 1997 14:37:36 -0400 (EDT)
>...
> > Laura Eaves wrote:
> > 
> > > The bug was that some links would change color as they were 
> > > "unhighlighted"
> > > while moving the current link around the screen.  It was necessary for the
> > > user to redraw the screen to restore the colors.
> ...
> > > THe problem seemed to happen when underlining was turned on in the 
> > > context of
> > > the link (for example, if in a <b> or <em> block).
> ... 
> > I sometimes see things like that with the "ncurses/SVR4 curses" color
> > code in the ongoing code set.  Should this change really be conditional
> > on SLANG only?
> probably not. But I've not seen any pages that do that - can someone point
> me to a misbehaving example so that I can analyze it?

I see it all the time.  One page that has links in mixed contexts is
http://www.newslink.org/

> Date: Fri, 11 Apr 1997 13:36:43 -0500 (CDT)
> From: Klaus Weide <address@hidden>
> ...
> The "problem" (which I hesitate to call a bug) is not specific to SLang
> or color.  It also appears with purely mono character attributes,
> if you happen to have a terminal(emulator)/terminfo combo that
> would make the different attribute combinations actually appear
> different on the screen.
> 
> (see <URL: http://sol.slcc.edu/lynx/klaus/texts/attrnotes.txt>)

If you use color and see it all the time, it's a BUG.
Your URL only documents it as a feature.

As for the problem occurring in other terminals and without -color,
does the problem occur even when not compiled with SLANG?
My reason for asking: highlight() in src/LYUtils.c contains the
following comment:

        if (flag == ON) { 
            /* makes some terminals work wrong because
             * they can't handle two attributes at the 
             * same time
             */
            /* start_bold();  */
            start_reverse();
#ifdef USE_SLANG
            start_underline ();
#endif /* USE_SLANG */
        } else {

If compiling with SLANG messes up some terminals even when not using color,
would a check for -color solve the problem? --

            start_reverse();
#ifdef USE_SLANG
            if ( !(Lynx_Color_Flags & SL_LYNX_USE_COLOR) ) start_underline ();
#endif /* USE_SLANG */

I don't have a way of testing this as I haven't seen the problem on my terminal.
If you could supply a URL and a TERM that fails (and ProComm emulates that
terminal) I could try it.

> What Laura did to fix the problem (just going by her description) still
> seems like a bit of overkill to me.  I'd prefer to still hold out waiting
> a bit longer for (an up-to-date version of) Rob's character style code,
> which should give a more general improvement of color behavior.

I've never tried Rob's style stuff.
If you could point me to where I can pick it up, I have time
to try it over the weekend.

As for whether it's a better solution in all cases, I use the
color slang stuff because I have trouble seeing reverse video
and can't read the lynx status line otherwise.
If Rob's style stuff doesn't let me redefine colors to something I can see,
then I can't use it, and will continue using/supporting the slang stuff.

As for my fix being overkill, the only alternative I saw was to search back
on the buffer for a "start underline" character, if there is such a thing
-- and that seemed a lot klugier and error prone.  Also, my fix is quite
simple and safe, if you look at it.  The only reason the diff was so large
is that I had to pass an extra arg (me->inUnderline) in all the calls to
HText_beginInput() and HText_beginAnchor().
--le

PS: I updated my temporary web page at http://www.intac.com/~leaves/
    but haven't changed the diff files of my fixes.  Since fotemods.zip
    seems to be unstable lately, I'm putting off picking up more of fote's
    fixes until things settle down.  I actualoy have this version built
    on 3 machines and a few people are using it.
    I've directed them to send bug reports to lynx-dev.
;
; To UNSUBSCRIBE:  Send a mail message to address@hidden
;                  with "unsubscribe lynx-dev" (without the
;                  quotation marks) on a line by itself.
;