Re: lynx-dev lynx2.8.3dev.4 - --force-empty-hrefless-a

[Vlad Harchev]

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