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

[Vlad Harchev]

On Sun, 2 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
> I do understand this.
> 
> I rather propose another way to do more things in LYReadCFG.c,
> for example add a field for initialization value into LYReadCFG.c table so a
> new function init_cfg() can be called from main(), this also necessary for
> reload_read_cfg() to work properly. So your script will not parse userdefs.h
> in this case but LYReadCFG.c table instead. Those are quite parallel ways.

 In general, my script doesn't parse userdefs.h (it can't be called 'parsing')
- it generates an include file consitsting of 'X':X where X is a name of each
setting, and prepends '#include "userdefs.h"' to entire file, and then calls
CPP, so I consider it's reliable enough, so we shouldn't worry.

 Adding 'default value' field will be not very easy. We have settings that
accept a list of arguments (like KEYMAP, VIEWER, DOWNLOADER, UPLOADER, SUFFIX,
RULE, PRINTER ...) - we should think how to be with them, also a lot of
default values are hidden in the lynx sources (like setting that has no
default value in 'userdefs.h' - eg a variable corresponding to it is directly
initialized in the .c file). Also after commandline options parsing some
caches are initialized (at least in LYPrettySrc.c if compiled with lss
support), so there should be the way to reinitialize them also. 
 I suggest adding 2 arrays of functions that must be called before
reloading lynx.cfg to free caches and that should be called after for
initializing caches just after loading lynx.cfg.

 In general, it will be hard to implement reloading lynx.cfg in a fully
correct way - it will take 2-3 weeks at least IMO. IMO we should focus on
adding any other user-visible options (like table support, JS support, piping,
key sequences, etc). Frankly speaking, I don't think reloading lynx.cfg is so
important and valuable - user can exit lynx, edit configs, and then run lynx
again, or even simply spawn another copy of lynx from lynx after editing
lynx.cfg to see the effect. 

> Also body.in syntax is not very simple, though understandable.
  
 Just keep in mind, that it will be processed by CPP, and the use of all
macros will became clear (ie you can't use literal quotes -they are mostly
unbalanced, hash (#), '//' - will be interpreted by GCC at least, '/*', and
that CPP is free to add spaces when substituting macros, etc..)

> >[...] 
> >  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.
  
  IMO we can do even better - read the list of settings, for which there is a
description, from a body.in - it has rather regular structure (extract 1st
argument for macros SETC and SETM), so we can avoid maintaining and shipping
/scripts/all_opts.

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

 Other solution for this can be simply removing 'Status' section (ie
conditionally defining it to nothing if some macro is defined).

>[...] 

 Best regards,
  -Vlad