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

[Klaus Weide]

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.

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.

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