lynx-dev
[Top][All Lists]
Advanced

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

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


From: Klaus Weide
Subject: Re: lynx-dev lynx2.8.3dev.4 - --force-empty-hrefless-a
Date: Thu, 15 Jul 1999 09:14:29 -0500 (CDT)

> > > > > * added support for forcing-empty-HREFless-As - ie A element that 
> > > > > doesn't
> > > > >   contain HREF will be closed after it was seen (without waiting for 
> > > > > </a>) -
> > > > >   this fixes rendering of documentation, produced by broken 
> > > > > translators that
> > > > >   don't emit balanced 'A's (eg RedHat docs produced by 'dlh', Sybase 
> > > > > docs) -
> > > > >   commandline option is --force-empty-hrefless-a, and 
> > > > > force_empty_hrefless_a 
> > > > >   in lynx.cfg, ifdef'd with NO_EMPTY_HREFLESS_A -VH
> > 
On Thu, 15 Jul 1999, Vlad Harchev wrote:
> On Thu, 15 Jul 1999, Klaus Weide wrote:
> 
> > It seems this change just enables a bit of code that was always there
> > but commented out [ ... ]

>  Try this (especially with color-style lynx).
> http://www.redhat.com/corp/support/docs/rhl/RHL-6.0-Manual/install-guide/manual/doc026.html
>  
> 
>  (to see the screen I see, you can use /samples/mild-colors.lss from the
> distro - everything is green (colored in the color corresponding to <a>)
> because the <a name=foo> at the begining are not closed (this file is produced
> by "dlh" translator). I don't have lynx without lss, but seems the screen will
> be awful like this too. 

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).

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.

I question whether the command line flag is 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".

> 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...

> > Don't think color-style-centric, most people don't use color styles.
> > 
> > There is also a dependence on whether BOLD_HEADERS is used (which
> > otherwise, I think, does have no effect on color-style coloring).

Sorry, I meant BOLD_NAME_ANCHORS.

> > I invented the SET_SKIP_STACK hack, but never checked whether using
> > it messes up the color-style stack of color styles; I suspect it does.


>  I didn't use this mode (since I don't read RH-install guide), but when I
> start working with Sybase, I'll use it. I hop SET_SKIP_STACK hack works OK.

Uhmm, are you saying you don't use your own patch for testing?  Not a good
endorsement...

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.

(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.")

> BTW, go to
> http://www.redhat.com/corp/support/docs/rhl/RHL-6.0-Manual/install-guide/manual/
>  and see how ugly the text at the bottom is. These are H1 !! Why there is no
> line breaks there?!

Because the simplistic recovery at the SGML.c level fails to close an
invalidly left open A, effectively all the H1 texts become part of one
mega-surrounding-H1, so no change of block style, so no line breaks
(split_line calls) generated.  See for yourself in a trace log.
(SOURCE view with -preparsed may also be enlightening.)

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.

   Klaus



reply via email to

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