Re: lynx-dev lynx.cfg bloat (was various fixes)

[Henry Nelson]

> preferable over any hide-the-comments-somewhere-else approach.

Just want to be sure I am not being misunderstood.  I am not, and
have never been, a proponent of separating comments from the actual
settings.  I think the present lynx.cfg actually is a reasonably
efficient way to configure Lynx.  I have pretty much mastered the
use of a text editor, and find it a very convenient way to do
configuration (much easier than those pull-down click-box menus
one gets with MSIE, where you have to open up five or more help
menus to figure out what is going on).  My main reason for getting
into the discussion is to try to keep the lynx.cfg mechanism easy.
I am not reactionary, i.e., I hope to see Lynx progress and evolve,
but I see no reason for new features to jeopardize the convenience
that exists.

What I do not like is the configure script automatically installing
the distribution lynx.cfg.  (The only workaround is the undocumented
copying of a personal lynx.cfg over the one in the distribution
breakout.)  I am vehemently opposed to creating a second file which
has essentially the same content as the distribution lynx.cfg.  I
don't see the point of adding debugging mechanisms or extraneous
help until the reloading mechanism is complete and fully tested.  It
is only at that time that _online_ help makes much sense.  I don't
see how these complaints are incompatible with having ONE, complete
lynx.cfg.

> Anyway, this is all just idle talk unless and until someone actually _does_
> something about it.  If not, then apparently the current state of the
> lynx.cfg is not enough of a problem.  No itch no scratching.

Quite true.  This is, however, an area where I have interest.  I may
even do "something about it," but not without first knowing what people
want (and that is very hard to find out).

> Actually that example goes in the opposite direction of what you want
> as policy (to paraphrase, I hope correctly, "make similar things
> suboptions of one option").  If they are similar enough to be explained
> together, they should probably be "something:PRINTER:..." and
> "something:DOWNLOADER:..."...

This is my view.  (Although, in this particular case where suboptions
can be very long strings and where there can be an indefinite number of
them, it might make more sense to keep it the way it is.)

> A simple patch to send.  (I agree FORCE_SSL_COOKIES_SECURE should be
> moved, I don't see any reason for the current placement.)

Not really a "simple" patch.  It is hardly worth shuffling the order
of lynx.cfg settings around if that is all that is done, IMO.  If I were
to do something, it would be to change that to COOKIES:FORCE_SSL_SECURE,
and change all the other COOKIE(S) options to COOKIES:FOO.  I think this
would _help_ guarantee that in the future like options would stay together.

Then what do we do about backward compatibility?  It is quite clear
that most people would not be willing to update their lynx.cfg.
New users and first-time installers would benefit without any pain,
but old-timers would really buck having to edit a bunch of defines.

The only thing I've been able to come up with is the creation of a new
define, something like CFG_COMPAT, that could be used to ifdef the old
code, both for parsing and decision-making throughout the source.  It
is quite simply impossible with my abilities for me to implement some-
thing like that in a reasonable manner.  If backward compatibility is
an absolute must, then I will definitely not be doing any work on lynx.cfg.

> But this can happen whether comments are in a different place or not,
> whether the .cfg file is split or not, right?

[So I was being misunderstood?]

> > o It would prevent growth and confusion created by "afterthoughts."
> >   This might be an inappropriate example, but what comes to mind is
> >   HISTORICAL_COMMENTS and MINIMAL_COMMENTS.  Putting aside whether
[...]
> A good example.  I think if these features were being added today, they
> would indeed be one option.  I certainly hope so.

*I certainly hope so*, too.  This touches on what I have referred to in
the past as "discretion" on what is integrated.

> Too bad.  Still, you seem to be in a small minority regarding your
> _strong_ opinions on the badness of those options.
                           ^^^^^^^^^^^^^^^^^^^^^^^^
My snide and inappropriate comments, my too "_strong_ opinions", were
directed at the *half-baked* (not "bad", but the incomplete, rushed [=not
thought through] and untested) way the configuration of the options was
implemented.  I also do not believe that "integrated" is synonymous with
"no longer changeable."

__Henry