Re: lynx-dev Re: what to do about html help files.

[Henry Nelson]

> If the information is put into the HTML files, then remove it from the
> lynx.cfg file.  However, frankly, I believe it belongs more in the
> cfg file than html file.

Okay, I'm going to break my promise and speak up.  Leonid, I agree 100%
with you that cattoc.html is a great innovation.  I think it holds a
LOT of promise.  The only area where we disagree is _how_ it is done.

I think if you and Vlad would give it time to mature and evolve, there
could be something quite useful created for Lynx users.  I sincerely
hope you and Vlad will work on it so that Tom can slap it into the
distribution at the very first round of the next develpment cycle
without any reservations.

Toward this end, if I may:
1) You have not convinced me that body.html is necessary.  I could envision
having one lynx.cfg (with a symbolic link to it from body.html -- maybe use
a name like lynxcfg.html, though) that contains "html" in it.  To use my
example of the other day:

##</pre><h2><a name="HISTORICAL_COMMENTS">HISTORICAL_COMMENTS</a><!--
##-->&nbsp; - <a href="cattoc.html#HTML">HTML parsing</a><!--
##-->&nbsp; ][ <a href="LYNXSETTINGSTATUS://HISTORICAL_COMMENTS">Status of this 
setting</a></h2><p><pre>
# If HISTORICAL_COMMENTS is TRUE, Lynx will revert to the "Historical"
# behavior of treating any '&gt;' as a terminator for comments, instead of
# seeking a valid '--&gt;' terminator (note that white space can be present
# between the '--' and '&gt;' in valid terminators).  The compilation default
# is FALSE.
#
# The compilation default, or default defined here, can be toggled via a
# "-historical" command line switch, and via the LYK_HISTORICAL command key.
#
#HISTORICAL_COMMENTS:FALSE

The illegal entities are a bit ugly to handle.  I would do it with a simple
explanation; others might prefer a sed one-liner to convert at installation.
A short gawk script could do most of the work; even hand editing would only
take an afternoon or so.

2) If this is deemed impractical, then an html version of lynx.cfg would be
necessary.  Above all else (this goes with 1 above, too), you must decide
what version you want to support, HTML2, HTML3.2, HTML4.  Doesn't matter
much which, but you have to decide and declare the doc type.  Only then will
you be able to write valid markup.  Next, I don't see how you can expect
us to swallow a document whose markup takes up as much space as the content.
All those <p>s, <br>s, <em>s, <hr>s, &nbsp;s, etc. are superfluous junk.
I would like to see you strive for a 4:1 ratio, content:markup.

3) No matter which route you go, it is totally unreasonable to have two
complete mechanisms for reviewing the active lynx.cfg file and the default
lynx.cfg.  The one that is already in there off of the = page isn't even
being used as is.  You talk about some 40KB compressed file, but in fact
you are asking (forcing, for the first two) people to install *3* lynx.cfg
files: their own, the 90+KB distribution lynx.cfg (needed for the
"Please read the distribution [1]lynx.cfg for more comments." link, and
now a 180+KB markup of the lynx.cfg under the help subdirectory.

If you chose to go Vlad's route, then completely backout all of the
lynx.cfg help that's in the code now: all those links to files, all those
gettext() messages and code generated html pages, LYNXCFG://reload/, etc.,
etc.  I think Vlad's way is much better, but it is a BIG undertaking to get
rid of the trappings that are going to be made obsolete.  It is not Tom's
responsibility to clean up after other people's mess.  I will continue to
lift the wool people are trying to pull over the eyes of lynx-devers.

__Henry