Re: lynx-dev suggested addition to lynx.cfg

[Vlad Harchev]

On Wed, 14 Jul 1999, Klaus Weide wrote:

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

 I can describe situation again (from my POV). I will do this on your request.
Here I'll add several hints only.
 
> 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)

 They generate both lynx.cfg (now with justification) (in a form very close to
present) and nice hyperlinked .html version.

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

    Tom denied to include them in lynx-2.8.2, but he wishes to add them to
  2.8.3.

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

 Those tools didn't modify lynx source. There was a patch that collects
information about each setting of lynx.cfg (in which of nested configuration
files given setting was changed and on which line and initialized with which
value, what is the last value of this setting read (and where it was
happened), provide the default compile-time value for this setting,and provide
information whether the defaul for this setting can be changed in userdefs.h
at compile-time, and tell whether the setting is accepted by current
configuration of lynx). You can see the demo at 
  http://www.hippo.ru/~hvv/lynx/demo1/
(select any setting, go to "View status of this setting" in subsection of this
setting). Or you can alternatively go to:
http://www.hippo.ru/~hvv/lynx/demo1/STARTFILE.html to see the output screen
for STARTFILE setting. Such screens are generated on the fly.
 The patch (ot 2.8.2dev25?) is placed at www.hippo.ru/~hvv/lynx/patch1.01.gz

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

 Yes, this is trivial for my tools since they are using C preprocessor - so 
defining conditional GENERATING_LYNX_CFG can turn parts of the file on or off
(and they generate lynx.cfg and *.html from file that is _based_ on lynx.cfg,
not current lynx.cfg). 
But Henry calls this a problem since he suggest another very small awk-based
tool that encloses entire lynx.cfg in <pre> and adds anchors to each option -
yes this will be the problem for hist tool.
  So, there is no problem for my tools, feel free to change the format of
lynx.cfg as you like.  
 
> 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?)
  
 If Henry tool are chosen instead of mine, then you have to.

>[...] 

 Best regards,
  -Vlad