Re: lynx-dev Re: what to do about html help files.

[Leonid Pauzner]

25-May-99 15:54 Vlad Harchev wrote:
> On Fri, 28 May 1999, Henry Nelson wrote:
...

>> > 4) Not yet fully implemented: reload the configuration files
>>
>> Aren't you in a sense turning lynx.cfg into .lynxrc?  If we allow reloading
>> of lynx.cfg, why not do away with it entirely and put everything onto the
>> Option Menu?  (Comments, Bela?)

>  There were ideas to make .lynxrc to be included by lynxcfg with special set
> of include restrictions (INCLUDE command allows it).
>  Now I think the best way to edit setting values at run-time is to provide
> input field or textarea on page LYNXSETINGSTATUS (since the
> LYReadCfg.c:Config_Table contains all info on how to handle option
> initialization it will be very easy to do) - seems this is MUCH better than
> reloading since you will be able to change the setting value interactively,
> without spawning external editor or reloading lynx. This way has some
> limitations (may be we shouldn't provide the ability to edit settings that
> aggregate their values like DOWNLOADER) - while "scalar" settins are OK.
>  Putting everything in options menu will require a lot of code to handle it -
> see LYOptions.c, and multiply its size by 10 -you'll get an impression of what
> should be implemented.

Interesting idea.
Originally, I implement LYNXCFG:/reload/ for testing purposes
to change certain settings online. This currently have lots of
limitations (interaction with command-line switches, options menu,
build-in defaults). In fact, we may need to change one
or maximum two cfg options the same time, so reloading
may be done for these options only (also have limitations but less).
This could be done via a separate screen dedicated to this selected
option (also additional info, etc. like LYNXSETTINGSTATUS://XXXX/ does).
Looks reasonable.  Non trivial alternative for forms-based option menu
(menu could not growth infinitely).

The only problem I want to mention here - we should write updated
lynx.cfg somehow so the changes will be activated for the next lynx
session also. That is a headache, especially when we have several included
cfg files. so it is uncertain how to write generated output automatically.
This may be somehow related with the utilization/unification of .lynxrc

Say, we add the string we intended to write to lynx.cfg -
into .lynxrc with a magic prefix. Than fix read_rc() and write_rc()
to parse these lines properly. So there will be no additional
files generated by lynx. (In this case .lynxrc should also be
reached from LYNXCFG:/ page). And don't forget interaction with
command-line flags.


>  IMO this message contains valuable ideas and possibly should be duplcated
> with another subject to force lynx devers to read those ideas.

>  Best regards,
>   -Vlad