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

[Henry Nelson]

> To all lynx developers: this message contains ideas I'd like to be read by all
> of you.

Amen to this because, besides having been driven absolutely crazy (yes,
it's true, Leonid), I'm tired.

>  As for configure script, IMO advanced users will be able to issue a 'mv -f
> lynx.oldcfg lynx.cfg' to fix it. 

The question is more like "should they have to?".  I'm also siding with
those sysadms (I'm one of them; that's why :) who MUST install Lynx,
but are virtual amateurs and, on the basis of past experience, trust Lynx
and Lynx developers to do right by them.  Some of these people don't even
know what `mv -f` is, much less that a lynx.oldcfg was created or even
what the path to it might be.  They type "./configure; make install."

>  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 
> we have to force like STARTFILE, so no documentation comments will be in the
> lynx.cfg. This will reduce distribution size and startup time.

I think all I've been asking for through this whole thread is some
consideration of such alternatives.  Note that this alternative was not
well received by one lynxdever, however.  I see some problems with it,
but it is in fact how I handle it on both my personal and system-wide
installations, and I like it.  I think the real solution is to put
lynx code and the configure script in line with each other.  That is, if
I am not mistaken, I don't think the configure script makes a distinction
between LYNX_CFG_FILE and LIBDIR/lynx.cfg.  The Lynx code, OTOH, makes
assumptions on the basis of the difference between these two.

>  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

I hate to open up fresh wounds, but this is where I have one real problem
with body.html.  I really don't think it is fair to bundle all of that
fancy printing/GUI markup in there.  If that's your goal, then give me a
pdf file I can download off of your site.

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

Absolutely.  It's a tradeoff.  In general you have the support of the
majority of Lynx users, so not to worry much about my comments here!

>  What do you mean by intercation of settings? Does LYNXSETTINGSTATUS://
>  suite you?

Not particularly, no.  I've said it before: it is not focused toward
its intended audience.  It does not help the average user; it is redundant
to the installing sysadm.

What I mean by interaction is thorough handling of not only what you call
"aggregate" settings, but also how _different_ settings may affect other
settings.  All I get from your present LYNXSETINGSTATUS is what I have,
but then I already know that because I see the behavior I'm getting from
Lynx.  In some cases knowing where in what file the setting that is in
effect was made will help (thus, I am not at all discounting your work
entirely) me debug my problem, but that is only because I know what each
of those settings mean in the first place.

>  Now I think the best way to edit setting values at run-time is to provide
                                                   ^^
"during" run-time?

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

If lynx.cfg can be reloaded, i.e., changed and those changes made effective
during a Lynx session, do we need LYOptions?  (The reverse of my question.)

> > >  So, IMO, LYNXCFG:// and LYNXSETTINGSTATUS:// complement each other,
[...]
>  IMO they don't overlap.

Only asking for time to see for myself.  I don't think I'm asking too much.

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

The main reason I took the bother to reply.

__Henry