Re: lynx-dev 'reloading' lynx.cfg (was: options (more, please))

[Leonid Pauzner]

16-Jul-99 07:47 Klaus Weide wrote:
> On Fri, 16 Jul 1999, Leonid Pauzner wrote:
>> 16-Jul-99 06:24 Klaus Weide wrote:

> It seems PRINTER, DOWNLOADER, UPLOADER, EXTERNAL lists are cleared.
> I overlooked the free_lynx_cfg() when I checked briefly before writing
> the above.

> RULE / RULESFILE aren't, but a call to HTClearRules() *may* be enough
> to do that.

RELOAD lynx.cfg was written from scratch on "help yourself" basis,
everyone who want to fix more exceptions may fix himself (as always).
This is a hack, see below.

> VIEWERs also aren't cleared, and that would be much more tricky
> since viewers end up in the HTPresentations list (maintained in
> HTFormat.c) together with MIME presenters / converters from
> various sources.  Also reloading now should put VIEWERs at the
> head of the list so the will have precedence; VIEWERs from lynx.cfg
> loaded normally at startup have the lowest precedence.  (should ==
> because I didn't test it)

> SUFFIX looks similar to VIEWER, entries end up intermixed with
> suffix mappings from other sources.

> Changing mailcap / mime.types locations won't have an effect.

> This (VIEWER/SUFFIX/mailcap/mime.types) could maybe be solved
> by clearing the lists and completely starting from scratch with
> HTFormatInit(), HTFileInit().  That means repeating more and
> more of the normal main() startup sequence in reload_read_cfg.

yes.
Originally, I thought that main() startup sequense may be splitted
into a separate function and called twice from different places.
But the problem is due to a pure implementation of different kind of settings
in main() so a medium rewrite of this function welcome.

Many problems may be eliminated by changing CONF_STRING to CONF_FUN
so the actions will take place just in case (from the other hand
we lost performance when having repeated entries). Probably something
equivalent to atexit() may be useful here, called after processing read_cfg().

Also I think we need to reload only *changed* values, not the entire set
(like I made for warnings when reloading forms based on the real changes
of the content) - this will prevent problems with the possible lost of
command line options (ones not affected with the changed lynx.cfg entries).
This will require to set a struct for all user-defined config options
to get a copy.

> KEYMAPs looks like another 'little' thing that doesn't work quite
> right; mappings done by the original lynx.cfg cannot be completely
> undone.  (Also the PASS flag I added cannot be undone.)

>    Klaus