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

[Leonid Pauzner]

>      * From: Vlad Harchev <address@hidden>
>      * Date: Sat, 1 May 1999 05:20:01 +0500 (SAMST)
>      * In-Reply-To: <address@hidden>


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

>  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
              ^^^^^^ LYMain.c
> 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

Surely, it is not so important, I just found it useful for testing purposes
when trying myself a new feature (say, SOURCE_CACHE or PARTIAL modes)
with different options. Not for everyday usage.

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

History/VisitedLinks lists may be important sometimes.