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

[Klaus Weide]

On Thu, 19 Aug 1999, Henry Nelson wrote:

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

Yes, having everything in one place _does_ have advantages...
OTOH if lynx.cfg consisted only of lines "INCLUDE:lynx-foo.cfg",
"INCLUDE:lynx-bar.cfg" etc. plus some comments, it should not be too
incomprehensible.

Not that I particularly want to propose that.  I just would find it much
preferable over any hide-the-comments-somewhere-else approach.

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.

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

Well, I have been very sceptical about some of them.  OTOH I am probably
also guilty in your view.

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

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

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

A simple patch to send.  (I agree FORCE_SSL_COOKIES_SECURE should be
moved, I don't see any reason for the current placement.)
But this can happen whether comments are in a different place or not,
whether the .cfg file is split or not, right?

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

A good example.  I think if these features were being added today, they
would indeed be one option.  I certainly hope so.

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

Too bad.  Still, you seem to be in a small minority regarding your
_strong_ opinions on the badness of those options.


   Klaus