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

[Henry Nelson]

>  I don't like the idea of combining body.html and lynx.cfg. Or lynx will be a
> software package that doesn't have separate documentaion on its configuration
> settings since all docs will be placed inside lynx.cfg.
>  And users are free do delete comments from lynx.cfg, so we shouldn't expect
> that the comments we emit to lynx.cfg will be there.

I sympathize with your thoughts.  However, I would like to give it more
thought, and also get others involved in thinking of other possibilities.

> > 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.
> 
>  As for number of files:
>  The user's own file can be of any size.
>  Users don't have to preserve distribution's lynx.cfg. LYNXCFG:// page says

They don't have to, but I ask, "how many Unix users of the configure script
are actually outsmarting it if they don't want that 90KB installed?"  The
install target automatically copies the lynx.cfg residing in the top level
directory to $LIBDIR.  (To make you feel better, I fought that battle, and
lost.)  From the top-level makefile.in:

install: lynx$x install-bin install-man install-cfg @INSTALL_LSS@
[...]
install-cfg : $(LIBDIR)
        -mv -f $(LIBDIR)/lynx.cfg $(LIBDIR)/lynx.oldcfg
        $(INSTALL_DATA) $(srcdir)/lynx.cfg $(LIBDIR)/lynx.cfg

>  This means that distribution's lynx.cfg is treated as documentation for all
> settings. If we'll intergrate body.in, then (IMO) this sentence will be
> changed something like this:
> 
> This is read from your lynx.cfg file,
> see documentation on the settings in lynx.cfg _here_. 
> 
>  or something like that referencing body.html or cattoc.html.

I think cattoc.html would be good.  I still maintain that you should
work on the configure script so it doesn't automatically try to install
the distribution lynx.cfg.  I'm simply asking for _one_ documentation
file that is _not bloated_.

>  As for useless of LYNXCFG:// page:
>  IMO it's very useful, since there are a lot of tasks that you can't perform
> using only LYNXSETTINGSTATUS:// url:
> 1) What files are read (remember INCLUDE command)
> 2) What settings are allowed in which file (remember extended syntax of
> INCLUDE command that allows included file to accept only subset of lynx

Not that I don't understand, but do remember my argument that the reason
you need this in the first place is that the configuration process has
evolved into something more complex than it need be.  If the configuration
process itself were simplified (or returned to its former state) there
would hardly be any need for all of this.

> 3) What settings were initalized in a whole (ie what settings don't take
> default value)

This is about the only function I really think is worth much.  A _true_
analysis of the interaction of settings would be useful, but I am repeating
myself.  Granted this is only my opinion as one user, and I have no
intention of forcing it.

> 4) Not yet fully implemented: reload the configuration files

Aren't you in a sense turning lynx.cfg into .lynxrc?  If we allow reloading
of lynx.cfg, why not do away with it entirely and put everything onto the
Option Menu?  (Comments, Bela?)

>  So, IMO, LYNXCFG:// and LYNXSETTINGSTATUS:// complement each other, rather
> then interfere.

No one thinks they interfere.  I don't understand if they complement or
simply overlap.  That's why I am begging for more time.  I guess as an
old-timer I hold stock in the expression: 'haste makes waste.'

__Henry