Re: lynx-dev [PATCH 2.8.3.dev6] various fixes

[Vlad Harchev]

On Tue, 17 Aug 1999, Klaus Weide wrote:

> On Sun, 15 Aug 1999, Vlad Harchev wrote:
> 
> > On Tue, 17 Aug 1999, Klaus Weide wrote:
> > > I find it likely that breaking these assumptions has more consequences
> > > than have so far been found.  It's not surprising that changes in
> > > anchor handling are needed; what is surprising is that the whole thing
> > > doesn't blow up in your face without more changes. :)
> > 
> >  Seems this is the only fix required [...]
> 
> Other cases to watch out for:
> 
>    ... some text <A HREF=...>anchor text</A> more text
>                 |
> 
>    ... some text <A HREF=...>anchor text</A> more text
>                  |
> 
>    ... some text <A HREF=...>anchor text</A> more text
>                                             |
> 
>    ... some text <A HREF=...>anchor text</A> more text
>                                              |
> 
> with '|' denoting the point at which split_line gets called (in other words,
> the point at which the line has reached maximum length).  Also with several
> spaces instead of one.  Variations that have en-space, em-space, nbsp, soft
> hyphen characters instead of, or in addition to, the normal spaces.

 I won't try e[nm]-space,nbsp, soft hyphen - these chars are absent in psrc
mode (since the entity's name is displayed, rather it's not rendered). As for
multiplie trailing whitespaces, I posted the patch yesterday (that prevented
trimming trailing whites in split_line).
 I'll try other variations, but seems they'll be ok - the problem my last
patch fixed was calculations of the line_pos and hightex2offset for anchors.
 Frankly speaking, I don't understand why you suggested such "testsuit" - 
IMO it should contain only breaks inside hightexts, the things you've proposed
don't contain them inside hrefs.
 But anyway, I hope (and will test) that everything is OK (and make sure
non-lss lynx renders correctly in psrc mode).

> Maybe all that is already taken care of - I don't know, I'm just suspicious.
> (The suspicion comes from finding and dealing with bugs in this area that
> were subtle enough to go unnoticed for several versions.)
>
> > > Maybe there should be a sub-mode of "prettysrc" in which anchors are
> > > not generated at all in the source view.  This would avoid problems of
> > > this kind, and also the 'inserted [nn] makes source invalid' problem.
> > > OTOH I don't particularly like an infltion of yet more options for
> > > prettysrc.
> > 
> >  IMO there are following solutions:
> > * Add lynx.cfg configuration setting like NO_ANCHOR_NUMBERING_IN_PSRCVIEW
> >   (seems this is most straightforward) - I'll probably try it today (I don't
> >   promise)
> 
> If you go this way, please consider: Logically the flag controlling
> anchor numbering should be a property of the HText instance, not a global
> variable.  Fight global variables. :)  Somewhat like text->hiddenlinkflag,
> which can follow or override the global LYHiddenLinks setting.

 Seems
 text->source && dont_number_links_in_psrcview

will be enough - if it yeilds true, then anchor numbering will be supressed.

> This would be simpler if the link-numbering aspect of 'keypad_mode'
> were divorced from the digit-key-mapping aspect - as repeatedly
> requested, discussed, but never done.
> 
>    Klaus
> 

 Best regards,
  -Vlad