lynx-dev
[Top][All Lists]
Advanced

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

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


From: Vlad Harchev
Subject: Re: lynx-dev When unhighlighting some highlighted links, lynx draws them incorrectly
Date: Thu, 18 Mar 1999 16:40:44 +0400 (SAMT)

On Wed, 17 Mar 1999, Klaus Weide wrote:
> [...]
> >         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).
  
   IMO, we can increase the value of MAX_STYLES_ON_LINE.
 
> However, since those are unusual circumstances, we may just use your
> method anyway, and later fix the glitches (or learn to live with them).

  Yes, IMO better anything than nothing. 

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

  There is a simple and nasty solution - we can create a new function from
 a curses_w_style, that won't do caching, and use it in
 draw_part_of_line.

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

  IMO, problems in those unusual situations will arise not due to my
patch, but due to bugs in other functions that deal with lss. IMO it's
better to rely on some buggy/untested code of other functions (problems with
which are so seldom visually detected) than don't fix apparent
problems. Anyway, lss support is still considered experimental so we are 
free to experiment with it :)

> [...] 
> > > 
> > > 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).
 
 IMO (as I understand) my patch is not guilty :) It sets the same
attributes as those ones will be set on ^L - the problem may be in the
parser(s) IMO.
  
> [*] 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. :)

  When you stop criticizing it :) Do you think it's correct?

>  [ ...] 
> 
>     Klaus
> 
 

 BTW: in function highlight:LYUtils.c your patch adds the following code:
 
            if (LYP >= 0 && LYP < CACHEH && LXP >= 0 && LXP < CACHEW) {
                s = cached_styles[LYP][LXP];
                if (s == 0) {
                    for (x = LXP-1; x >= 0; x--) {
                        if (cached_styles[LYP][x]) {
                            if (cached_styles[LYP][x] > 0) {
                                s = cached_styles[LYP][x];
                                cached_styles[LYP][LXP] = s;
                            }
                            break;
                        }
                    }
                    if (s == 0)
                        s = s_a;
                }
            } else {
                s = s_a;
            }
            LynxChangeStyle(s, STACK_ON, 0);
        }
 Why LynxChangeStyle(s, STACK_ON, 0) /* (0) */? May be it will be better
    LynxChangeStyle(s, ABS_ON, 0);  /* (1) */
 Currently it doesn't hurts since "ABS_OFF is the same as STACK_OFF for
the moment" in curses_w_style - and there is a call in the 'highlight'
   lynx_stop_link_color (flag == ON, links[cur].inUnderline);
later, and lynx_stop_link_color consists of the call
   LynxChangeStyle(flag == ON ? s_alink : s_a, ABS_OFF, 0);
At my (current) level of lss understanding  /* (1) */ is more correct than 
/* (0) */ - there can happen attribute stack overflow when ABS_OFF will treated
different from STACK_OFF (I assume that my patch will be applied later) 

  Best regards,
  -Vlad  
  


reply via email to

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