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

[Henry Nelson]

> Someone may want to propose a partitioning scheme.  Instead of one
> big lynx.cfg, have a small lynx.cfg that includes other files.
> Most or all INCLUDEs could be commented out by default.

Having a "scheme" seems really important to me.  Although I don't much
care for the INCLUDE idea, I also realize I am in the minority and that
it is here to stay.  What "scares" me most about it, though, is ending
up with an unorganized conglomeration of arbitrary names for the various
files.  When someone writes in for help, answering them with "take a
look at your lynx.cfg file" would be just taking a shot in the dark.

> The number of options _will_ continue to grow, or does anybody expect

I am talking about the _rate_ of growth, and the _importance_ of some of
the recent additions to Lynx _as a WWW browser_.  I'm sorry, but I simply
do not agree that all of the recent additions in the name of "flexibility"
and "preventing loss of precision" are justified _in lynx.cfg_.  IMHO,
much of it is quite esoteric and has very little to do with people accessing
and enjoying the Internet.

> > > e.g., PSRCVIEW:NO_ANCHOR_NUMBERING and PSRCVIEW:NO_LINKS.
> 
> I don't see how this would help keeping lynx.cfg smaller.  The stuff
> still has to be documented, that's what takes up most of the space.

"Smaller" is hardly all I'm concerned about.
o Documentation by function, rather than by setting, might be more
  effective in some cases. (cf. PRINTER & DOWNLOADER DEFINITIONS) 
o I would not like to see related settings getting orphaned.  For
  example, I would rather have FORCE_SSL_COOKIES_SECURE right next
  to the other COOKIE(S) settings, whether directly related or not,
  rather than being separated by a dozen or so completely unrelated
  settings (and a hundred or more lines).
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
  settings that can be toggled by a key really need to be in lynx.cfg
  at all, these two could very easily have been done as COMMENTS: with
  three (or more) arguments, HISTORICAL, MINIMAL and VALID.  The
  user wouldn't have to worry about what overrides what; I should think
  the programmer would have less headaches concerning backward
  compatibility.

> > > There is no excuse other than laziness and sloppiness
> > > for junk like the HTMLSRC_* fiasco.
> 
> Or exuberance.

Your comment is well taken.  I apologize for these objectionable
and unpleasant remarks.  There is no place for them on this list,
and no excuse for my rudeness (other than being a hick cowboy).

> like "junk" and "fiasco" are a bit too strong.  Probably not the most
> effective way to get it changed, if that is what you want.

Cattle prod.  The author categorically stated that he would not
implement improved handling.

__Henry