lynx-dev
[Top][All Lists]
Advanced

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

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


From: Vlad Harchev
Subject: Re: lynx-dev [PATCH 2.8.3.dev6] various fixes
Date: Sun, 15 Aug 1999 21:41:16 +0500 (SAMST)

On Tue, 17 Aug 1999, Klaus Weide wrote:

> On Sun, 15 Aug 1999, Vlad Harchev wrote:
> 
> >  This is the patch that fixes yet another bug in justification code (anchor
> > position recalculation) and fixes the GridText.c:*TrimHightext (it was not
>                                                                   ----------
> > designed to support LY_SOFT_NEWLINES) - this corrects rendering of links on
>   ------------------------------------
> > wrapped lines in psrc mode.
> 
> A comment on the underlined sentence:  Yes, that's basically correct.
> The -prettysrc mode breaks several invariants (things that, so far, were
> always true):
> 
>  - There are no anchors in source mode.
>  - LYK_SOFT_NEWLINE only occurs in source mode.
>  - LYK_SOFT_NEWLINE never occurs in a document that has any anchors
>    (a direct consequence of the previous two).
> 
> 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 (since IsSpecialAttrChar is defined
as 
#define IsSpecialAttrChar(x) (x >0x02 && x < 0x10)

 or something like this (but "x>0x02") is definitely in its definition, not
">=", while the value for LY_SOFT_NEWLINE is 0x02. So, (I hope) these are the
only things required to support LY_SOFT_NEWLINE in the document where links
are present...
 BTW, change to justification code mentioned in comment to the patch is
unrelated to the handling of the LY_SOFT_NEWLINE - all changes for support of 
LY_SOFT_NEWLINE are in *TrimHightext - 2 expressions only.

> These remarks are not based on any examination of how the new
> prettysrc and justify stuff works, just on my understanding of how
> things used to be.
> 
> 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)

* Add lynx.cfg setting like NO_LINKS_IN_PSRCVIEW - (seems to be
  straightforward and even simplier than 1))

* Allow toggling to the 'plain' source view from psrc mode (some key to be
  invented, difficult for me since I am not familiar with lynx keybindings)

* Leave the things as they are now - nasty approach - user can press ^H, then
'p' or 'd' and then do what (s)he wants. As I remmeber, current SOURCE_CACHE
 mode doesn't help when 'p'rinting or 'd'ownloading - ie the cache is not used
 - so we could hack SOURCE_CACHE mode in order to do this to compensate
 download time.


>    Klaus
> 

 Best regards,
  -Vlad


reply via email to

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