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

[Vlad Harchev]

 To all lynx developers: this message contains ideas I'd like to be read by all
 of you.
 
On Fri, 28 May 1999, Henry Nelson wrote:

> >  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 configure script, IMO advanced users will be able to issue a 'mv -f
lynx.oldcfg lynx.cfg' to fix it. 
 IMO we can make distribution's lynx.cfg very small - less than 1KB - by
placing a comment like "see body.html for documentation" and few settings that 
we have to force like STARTFILE, so no documentation comments will be in the
lynx.cfg. This will reduce distribution size and startup time.
 Having documentation in html is equal to having docs in billions of
renderings. Why should we maintain lynx.cfg comments that are only in one
rendering (tho' maintaining comments is not techincally difficult)?

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

 Simplification = loss of flexibility here.

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

 What do you mean by intercation of settings? Does LYNXSETTINGSTATUS://
 suite you?
 
> > 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?)

 There were ideas to make .lynxrc to be included by lynxcfg with special set
of include restrictions (INCLUDE command allows it). 
 Now I think the best way to edit setting values at run-time is to provide
input field or textarea on page LYNXSETINGSTATUS (since the
LYReadCfg.c:Config_Table contains all info on how to handle option
initialization it will be very easy to do) - seems this is MUCH better than
reloading since you will be able to change the setting value interactively,
without spawning external editor or reloading lynx. This way has some
limitations (may be we shouldn't provide the ability to edit settings that
aggregate their values like DOWNLOADER) - while "scalar" settins are OK.
 Putting everything in options menu will require a lot of code to handle it -
see LYOptions.c, and multiply its size by 10 -you'll get an impression of what
should be implemented.
 
> >  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.'

 IMO they don't overlap.
 
> __Henry
> 

 IMO this message contains valuable ideas and possibly should be duplcated
with another subject to force lynx devers to read those ideas.

 Best regards,
  -Vlad