Re: lynx-dev When unhighlighting some highlighted links, lynx draws them incorrectly

[Klaus Weide]

[ Not cc'd, by request; you don't need to cc me either, but I don't
 mind.  Occasionally the mailing list acts up, or it takes a while
 to propagate messages. ]

On Sun, 14 Mar 1999, Vlad Harchev wrote:
> On Tue, 16 Mar 1999, Klaus Weide wrote:
> 
> > On Sun, 14 Mar 1999, Vlad Harchev wrote:
> > > On Tue, 16 Mar 1999, Klaus Weide wrote:
> > > > I suspect that this can create the kind of problems [ ... ]
> > > 
> > >      Yes, now I've realized that it can. I see a clean solution:
> > >   [...]
> > >           Now I think that it should be:
> > >   LynxChangeStyle (CStyle.style,ABS_ON,CStyle.previous);
> > 
> > That's nice for the ON changes, but won't work for the OFF changes.
> 
>   I was wrong - the solution I've suggested was incorrect. It shouldn't be
>  LynxChangeStyle (CStyle.style,ABS_ON,CStyle.previous);
>  It should be as it was - I found a nice feature of LSS - see below.
> 
> > [ ... ]
>    
>         Here what I've found:
>   In each HTLine, all styles are balanced, ie the # of styles with
> (dir==STACK_ON) == # of styles with dir==(STACK_OFF) in each line. 

That shows that the USE_COLOR_STYLE stuff in split_line() is working,
in the cases that you have tested.  It is working in more cases now,
after the change from my patch, but it is still not always guaranteed.

I have now seen at least one page where this doesn't seem to be true,
involving invalidly nested tags, when TagSoup parsing is in effect.
Also all bets are off when the fixed limit of MAX_STYLES_ON_LINE is
exceeded (not tested).

However, since those are unusual circumstances, we may just use your
method anyway, and later fix the glitches (or learn to live with them).

> So, if
> you apply all styles in the line in a sequence, the last_ptr (stack position)
> will remain unchanged (if there are no others bugs in lss code). So, the
> patch I've sent originally does correct thing - it applies all styles of
> HTline, but draws only the required part of a line. After drawing that
> part it sets remaining styles of a line, no loops should be altered in
> patch I've originally sent.

There is another potential problem with that, a side effect of curses_w_style:
it sets cache_styles[YP][XP] to the attributes from the last ON change.
But this can now occur at the wrong coordinates for style changes after the
anchor.  I expect this to create a problem for something like
   ....
   <A ...>anchor text 1</A><A ...>anchor text 2</A> <B>more stuff</B>
   ...                                               ^ last ON change on line

(The B STACK_ON change would be saved at the position where the second
anchor starts when the first anchor is unselected - untested)

> I've composed an html of your examples with
> line breaks you've mentioned , and debugged lynx - last_ptr is always =0
> after each link is unhighlitten - especially I've stepped through
> 'redraw_patr_of_line' for the last sample with 3-line anchor - it's OK.

Good. :)   There are still unusual situation where it wouldn't
be the case, but we could ignore them for now if you wish.

> And of course :), links unhighlighting is done correctly. I've tested lss
> file that is shipped with dev19 - ie before applying your patch.
>   
> > Something like: take care that the stack doesn't underflow (i.e. don't
> > pop more than we push in one anchor's extent, and restore pointer at end
> > of anchor's extent to what it was before.
> 
>       It seems that all assertions are already implemented in 
>  'curses_w_style'.

It makes sure that last_colorattr_ptr >= 0; I was thinking of a stricter
check 
  last_colorattr_ptr >= [ saved value at beginning of anchor's extent ]

> > [...]  
> > 
> > Here is a page that shows another effect; does your patch deal with it?
> > 
> >   <http://www.ietf.org/>
> > 
> > (You need to have styles for A and IMG that are different in order to
> > see it.)
>  
>   Sorry I didn't tested - browsing Inet is a pain for me. Can you describe 
>   the effect?

It has links like (simplified examples)

  <A HREF="."><IMG ALT="" SRC=".">Some text</A>
and
  <A HREF="."><IMG SRC="."> Some text</A>

(The first kind may have to be nested in some other element that ends on the
same line, in order to see the effect.)

Without your patch[*], unhighlighting uses the IMG style for the whole link
text (or for the part that is on the first line, if the anchor is split
across lines).

[*] I still have not tested it, hoping that Tom will put my patch in dev.20
    and that you will then send an updated patch. :)

[ diverging from the main topic now... ]
> > Actually there's more questionable stuff in this area - it seems that the
> > total number of lines (as shown on the '=' screen and used for 'P'rint)
> > is off by one for HTML documents.  [...]
> 
>   May be the value should be simply corrected when displayed on the
>   '=' screen ?  This will require small modification. 

Yeah, but it's a bit more complicated than just adding 1 whenever the number
of lines is shown, because *sometimes* text->Lines is already correct.
To avoid confusion, it would be better to set text->Lines to what it appears
to mean: the number of lines in the text.  It's only a minor annoyance,
maybe someday it'll get fixed...

    Klaus