[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