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

[Vlad Harchev]

On Fri, 28 May 1999, Leonid Pauzner wrote:

> 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

 We can provide following radiogroup:
 * save new value in host-wide file (this option can be allowed for root only)
 * save new value in user-wide file
 * don't save new value
 
 Since saving new values of options is a great security hole, there should be
commandline options or settings that will control this.
 If allowed, I think of the following:
  if saving in host-wide file was requested, then append the valid string to
 file '$(libdir)/lynxcfg-runtime-saved'. For this to work, we should append
the line 
      'INCLUDE:lynxcfg-runtime-saved'
to the end of lynx.cfg (ie if we don't append, that file won't be read - good 
control over it).
  If saving in user-wide file, then append the valid string to
~/lynxcfg-runtime-saved - to allow this settings to take effect, the line
      'INCLUDE:~/lynxcfg-runtime-saved'
should be added to the end of lynx.cfg.
  Such approach will allow great control over it and won't require any
modification to .lynxrc and to code that parses .lynxrc. By omitting those two
INCLUDE lines we make lynx save since no changes will take effect. We can add
filenames to which lynx will write saved settings - they can be /dev/null in
order not to waste disk space.


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

 Best regards,
  -Vlad