Re: lynx-dev suggested addition to lynx.cfg

[Klaus Weide]

On Wed, 14 Jul 1999, Henry Nelson wrote:

> > I don't particularly care for "a battery of management tools" for lynx.cfg,
> 
> I don't either, but we'll probably be getting them.  Maybe you weren't here
> in May when half of the traffic on the list was rebuttal and counter
> rebuttal between Vlad and me on the pros and cons of his proposals.

Oh yes, I remember - I just wasn't following THAT closely, and without
following really closely I found it all quite confusing.  I was kind
of waiting for the "executive summary".  There were some messages from
Vlad that seemed to nearly summarize it, but then yet another aspect
came up...

My attempt of summarizing what I came away with:
 1. Vlad made some tools that do something nice to a lynx.cfg file.
    (fine by me)
 2. Vlad wanted those tools (or the output of those tools?  or both?
    or part of each? or documentation changes? here is where I'm most
    confused) to be included with the lynx package.  Tom denied that.
    (fine by me)
 3. An HTML'ized description of settings is availabe on the Web, according
    to a pointer in current lynx.cfg, at 
    <http://www.hippo.ru/~hvv/lynxcfg_toc.html>.
    (fine by me too)
 4. Maybe there was something more, like generating lynx.cfg (from what?
    when where and who?), but it becomes very hazy..

Well so far the only one who has to batter with the battery seems to be
Vlad, and that's because he chooses so, right?

I don't think there was anything that requires us normal lynx hackers (who
do no want to care too much of those "management tools" questions) to
change the ways of our daily lynx hacking.  It least, nobody briefed me.
So I continue to work on the assumption that it's not my problem.

> > > to?  Is your proposal so different from the following?
> > > #INCLUDE:~/.lynx.cfg:INCLUDE [other allowed settings]
> > 
> > I don't know what you mean by that.  Just one line without explanation?
> > What exactly, from the current lynx.cfg and/or my suggested additions,
> 
> Seems to me you wanted to let the user have the global defaults and override
> only what he/she wanted.  Can't that be done by the above line without any
> requirement about it's placement in the "main" lynx.cfg file?  By allowing
> INCLUDE in the user's personal lynx.cfg, they could then INCLUDE the "main",
> or global, lynx.cfg themselves.

So you would have at least three files involved?  I still don't quite
understand whether you mean A -> B -> A or A -> B -> C.  That seems too
complex as a default suggestion, and would need more descriptive text.

> > Another question (IMO) is whether the stuff about the "more powerfule"
> > INCLUDE starting with "Starting with Lynx 2.8.2, ..." should also be
> > moved to the end.  You may want to suggest that separately.
> 
> I did just that in my previous post.  

Well I meant only the second part of the INCLUDE text that's now at the
beginning, while you wrote about moving all the INCLUDE stuff to the end.
You also wrote "It seems more logical to have it the first one, however."

Ok, on thinking about it again, it makes more sense to have all the
INCLUDE stuff described together.  I also think most people would
normally use INCLUDE, if at all, at the end of a system-wide lynx.cfg.
(That may be because I haven't understood your INCLUDE:...:INCLUDE thing.)
So let's move all of it to the end.  But since INCLUDE is kind of an
exceptional meta-option, it seems also logical to mention it right at the
start.  So let's just have one short sentence near the beginning that says
"This file can include additional configuration files, see description
of INCLUDE near the end".

> My point is that if an htmlized
> lynx.cfg is to be generated from the static one in the top directory, each
> define needs to be extracted exactly one time to form the pseudo links.
> Having multiple entries of the same defines separated by many other defines
> makes that process no longer a trivial matter.

I assume that would be Vlad's problem, and he hasn't mentioned it.
So maybe it is already trivial for his tools.  I'm just guessing.

But it makes sense to describe the aspects / uses of INCLUDE together,
also for the human reader of the "raw" lynx.cfg, not just for the tools.
If it were only for those tools, I'd say those tools have to improve.

(Out of curiosity, you seem to be 'against' those tools, I'm surprised
then that you care so much about making things easy to process for them?
Should I start to worry about the lynxcfgeating monsterscriptcollection
too?)

> > / a suggestion.  My additions don't HAVE to be at the end, that's just
> > the place where the INCLUDE most likely achives what most people want
> > by just un-commenting it.  Administrators and users who want to spend
> 
> So that's where it idealy *should* be placed in the distribution lynx.cfg.
> (And someone has to keep it there.)

Ok so it seems we agree.
(Should we nail it to the ground somehow?)

> > options in place can to whatever they like, as always.  I don't see
> > how this creates any burden for you.  Or for anyone who installs lynx,
> 
> It creates no problem for me, nor for the user, nor for the installer.
> The burden falls on the coordinating developer.  Maybe Tom doesn't mind
> always checking for little things like that, but it would drive me batty.

The purpose of having this long discussion about minor points is so that
he'll always remember. :)

Anyway, I hope anyone planning to remodel lynx.cfg would realize that INCLUDE
deserves special attention (because of what it is and does), and would not
just put it in alphabetical order between HTMLSRC_TAGNAME_XFORM and INFOSECS
or something equally pointless.


    Klaus