Re: lynx-dev structured description of lynx.cfg settings

[Vlad Harchev]

On Sat, 1 May 1999, Leonid Pauzner wrote:

>[...] 
> This can be a maintenance problem for lynx.cfg future.
> Currently we need to add a line into LYReadCFG.c table
> and drop a comment into lynx.cfg, now we need to change
> in sync several files under scripts/ directory also.
> 
> Is it possible to change LYReagCFG.c table format to add
> several fields above into that king of structure?
> (probably we need an aux program gotten from a separate compilation
> of LYReadCFG.c with other options to exclude long text fields
> like "description" from a regular lynx binary).
> This also adds a portability for non-UNIX lynx ports.
> 
> [...]
 Nothing that is generated from files in /scripts gets to lynx binary - it
gets to $(helpdir)/lynxcfg/* - so it won't increase lynx binary size. IMO we
shouldn't import that html file generated to be embedded in the binary. This
will prevent lynx developers from writing complete descriptions. Other
information (about whether the option is accepted or ignored, it's default
value - is automatically extracted for LYReadCFG.c by scripts - and this
allows reading generated html file with any other browser, references to
settings' descriptions from other help files - ie it's a 'real' html file in
any sense.
 I propose to stop modifing /lynx.cfg by hand, edit /scripts/body.in -
lynx.cfg and html file are generated from it. There are facilities that allow
emitting uncommented strings to lynx.cfg when generating it - so (I hope and
don't see any techincal objections against it) we should modify only
/scripts/body.in from this point ( and insert value that we recommend thu' not
default as settings to generated lynx.cfg).
 When adding new settings to table in LYReadCFG.c you should add the name of
the setting uppercased to /srcipts/all_opts (and of course description of it to
/scripts/body.in). Nothing else need be touched. I provided several files
(like list of categories, category's descriptions) in /srcips/* in order lynx
developers to modify it if they find categorization or categories' description
incorrect/unclear.
 See also /scripts/README for more description.

 As for troubles with ports to other non-unix OSes - typically they are
acquired precompiled. So, the person who does compilation (for those weird 
OSes) will have trouble (only that person, not the end users). One solution of
this can be the following:
 Configure lynx with everything enabled, define the values that will be
changed in port to weird OS as they will be when configuring for it, and
generate documentation. Disadvantage of this will be 'accepted' in 'Status'
for most of options (while several options will be 'ignored' instead by
configuration of lynx for weird OS).

To TD:
 Are you testing that patch? Are there any problems?

 Best regards,
  -Vlad