[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: lynx-dev lynx2.8.3dev.4 - --force-empty-hrefless-a
From: |
Vlad Harchev |
Subject: |
Re: lynx-dev lynx2.8.3dev.4 - --force-empty-hrefless-a |
Date: |
Fri, 16 Jul 1999 05:39:00 +0500 (SAMST) |
On Thu, 15 Jul 1999, Klaus Weide wrote:
>[...]
> And I currently don't have most recent lynx *with* lss...
> Your assumption is wrong, since those anchors aren't hightlighted
> in any special way - except when BOLD_NAME_ANCHORS is used (see correction
> below), which is just the case when --force-empty-hrefless-a does nothing!
> (via the me->inBoldA test).
Seems that any lynx with lss is required to see that effect - not the most
recent. Tweaking BOLD_NAME_ANCHORS (setting it to T or F) won't cure that
effect on dev3,dev4 - seems that color read from .css file is emitted
regardless of that setting.
Why don't you use lss-enabled lynx?
> So your new flag in its current for is only useful for color-style users.
> And it doesn't really "force" anything - the effect is still effectively
> disabled by BOLD_NAME_ANCHORS:TRUE.
>
> Actually, it seems: in effect, for color-style users, toggling your flag
> has exactly the same effect as enabling the code (removing ifdefs) and
> then toggling BOLD_NAME_ANCHORS.
See above. It seems that this commandline switch and lynx.cfg setting should
be allowed only in lss lynx.
> I question whether the command line flag is useful.
Yes, may be it's not useful.
> Also the name is inconsistent with the usage in BOLD_NAME_ANCHORS:
> what's called a "name anchor" there you call an "hrefless a".
This was the Fote terminology.
> > Then try with --force-empty-hrefless-a (it will close
> > hrefless are as they seen, so the screen will be correct).
>
> I haven't compiled with it yet...
I tested this patch on these screens.
>[...]
> Uhmm, are you saying you don't use your own patch for testing? Not a good
> endorsement...
I tested it (I browsed RH-install guide for 5 minutes and found it working).
OK, I'll enable it right now in lynx.cfg :)
> Actually, the primary hack is to call HTML_end_element from within
> HTML_start_element (not my invention). Fote did that for some elements
> (especially A) in what's-now-known-as-TagSoup mode. SET_SKIP_STACK is my
> secondary hack to make the first hack work (better?) in SortaSGML mode.
> But all that never really took color-style into consideration - it's
> experimental after all...
>
> Both with or without your --force-empty-hrefless-a active, the internal
> HTML_end_element call with SET_SKIP_STACK occurs at some point for
> some of those unclosed anchors (at the point where the "too much green"
> ends, probably). The --force-empty-hrefless-a just makes it happen
> as early as possible, so you don't see the mess-up, but it's still there
> and may still bring the color-style "stack of color changes" out of synch.
> (Look carefully whether everything *after* such a point is recovered
> right.) You should also check whether defining/undefining OPT_SCN and /
> or OMIT_SCN_KEEPING changes anything.
>
> The much better solution for recovering from this kind of mess would be
> to detect the invalid nesting at the SGML.c level, and close the A right
> there.
This nesting can't be detected in a right way (I meant it can be detected,
but too late - when the screen will be ugly). So finishing the <a> as soon as
possible is the only solution (and it can't be done in SGML.c IMO or could
be done without introducing generic approach but using only A-specific code).
> (Another solution is to say "this is so messed up, don't try to cover
> up for it. After all the text is still there and readable.")
I prefer to consider the -force-empty-hrefless-a to be another hack useful
for eveybody. And you will be responsible for it since it uses your
SET_SKIP_STACK hack :)
>[...]
> There are flags for what elements can close what kinds of elements,
> but they do not distinguish between detecting an error at a start tag
> and detecting an error at an end tag. We don't allow an <H1> to close
> a still-open <A> to avoid generating a "hidden link" in some cases,
> but that also means that a </H1> cannot close an open <A>. At that
> level we also don't keep track of which A's were hrefless. But adding
> some more fine-grained control at the SGML.c level for when recovery
> can occur would be better IMO than mucking around in HTML.c for this.
Yes, may be, but it requires time..
> Klaus
>
Best regards,
-Vlad
- lynx-dev lynx2.8.3dev.4, T.E.Dickey, 1999/07/14
- Re: lynx-dev lynx2.8.3dev.4, Heather Stern, 1999/07/14
- Re: lynx-dev lynx2.8.3dev.4: "stubbing off hotlinks"???, David Combs, 1999/07/14
- Re: lynx-dev lynx2.8.3dev.4, Vlad Harchev, 1999/07/15
- Re: lynx-dev lynx2.8.3dev.4 - --force-empty-hrefless-a, Klaus Weide, 1999/07/15
- Re: lynx-dev lynx2.8.3dev.4 - --force-empty-hrefless-a, Vlad Harchev, 1999/07/15
- Re: lynx-dev lynx2.8.3dev.4 - --force-empty-hrefless-a, Klaus Weide, 1999/07/15
- Re: lynx-dev lynx2.8.3dev.4 - --force-empty-hrefless-a,
Vlad Harchev <=
- Re: lynx-dev lynx2.8.3dev.4 - --force-empty-hrefless-a, Klaus Weide, 1999/07/17
- Re: lynx-dev lynx2.8.3dev.4 - --force-empty-hrefless-a, Vlad Harchev, 1999/07/17
Re: lynx-dev lynx2.8.3dev.4, Vlad Harchev, 1999/07/15
Re: lynx-dev lynx2.8.3dev.4, Leonid Pauzner, 1999/07/15
Re: lynx-dev lynx2.8.3dev.4, Leonid Pauzner, 1999/07/15
Re: lynx-dev lynx2.8.3dev.4, pg, 1999/07/15