Re: lynx-dev lynx2.8.2pre.7

[Vlad Harchev]

On Thu, 27 May 1999 address@hidden wrote:

> > 26-May-99 18:50 Doug Kaufman wrote: 
> >  
> > Hmm, Doug. 
> >  
> > > I still haven't had a chance to evaluate the new files, but I do have 
> > > some comments about these exchanges. It seems that we are drifting 
> >  
> > "I haven't read the book by have an opinion..." 
> > Let we include this files into pre-release and you got a chance to look at 
> > it! 
> 
> Frankly, adding those files to pre-release will only increase the time
> before release.  (And I'm opposed to including generated files without having
> a stable/portable version of the tools used to generate them - I thought I'd
> made that clear during the past month).
 
 The tools that generate the files musn't be portable - I suppose that only
maintainer will use them on his machine to generate body.html that will be
included in distribution (I assume that maintainer's machine is powerful
enough), and those tools won't be included in the distibution (but can be
distributed separately).
 IMO they are portable now.

> > Further actions may be to improve HTML layout slightly or remove files 
> > before 
> > the actual release. So I am confused with our "battle", 40K in a zipped 
> > distribution or in gzipped help is not a problem. There is nothing terrible 
> > difficult to remove these files after a couple of pre-releases if we find 
> > them 
> > redundant. 
> 
> the basic issue is that you're proposing adding maintenance effort - each
> time someone wants to modify lynx.cfg, we'll have a delay while it is also
> applied to the parallel html'ized version.
> 
> better to think carefully about this and propose (in 2.8.3) a format that
> can generate both the flat lynx.cfg as well as the html files.

 Even 1st release of /scripts patch (that was released ~ month ago) generates
lynx.cfg, and it emits default value of each setting and status - whether it
is accepted or not. I designed body.in to be the source of generated
documentation and lynx.cfg from the very begining. I just forgot to mention
it (or forgot whether I mentioned it). I supposed that all modifications will
be made to body.in, and lynx.cfg will be regenerated after each mods. The set
of macros already allows emitting setting initialization when generating
lynx.cfg - ie ability to generate uncommented lines in lynx.cfg.

 Current state of matters (generated lynx.cfg is supplied, and not generated
to reflect default values of configuration, and probably we don't ship
/scripts dir in distribution) prevents us from generating lynx.cfg so that
default values will be reflected in it by scipts. But, when my patch applied,
and with help of another script, it will be possible to generate lynx.cfg
reflecting default values and status of the settings, by rendering 
LYNXSETTINGSTATUS://XYZ for each setting XYZ and embedding required part of
that report to lynx.cfg - such script will require only sed and bash, no cpp.

>[...] 

 Best regards,
  -Vlad