lynx-dev
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: lynx-dev extending the syntax of 'include' command in lynx.cfg


From: Vlad Harchev
Subject: Re: lynx-dev extending the syntax of 'include' command in lynx.cfg
Date: Wed, 14 Apr 1999 13:44:00 +0500 (SAMST)

On Wed, 14 Apr 1999, Leonid Pauzner wrote:

> 14-Apr-99 03:24 Vlad Harchev wrote:
> >  More brave approach:
> >  Make ~/.lynxrc to be included by lynx.cfg (it's syntax must be changed to 
> > one
> > of lynx.cfg), with a list of options it can contain in the 'include' line. 
> > As
> > I understand, with  LP's patch lynx.cfg can be edited at runtime and 
> > reloaded
> 
> Right. BTW, does it work for your prettysrc settings:
> I saw a DTD fix before read_cfg() in LYMain.c, so assume may be a problem
> when reloading changes in another current DTD or so. Is it OK for you?

  As long tag names in both DTD are the same at the same indexes, it doesn't
matter what DTD it is. I use tag names to compute hashes of tags.
 
> >  in the same session - such feature as editing options specified in .lynxrc
> >  at runtime is not the major privelege (or feature) of .lynxrc. So, a huge
> > section of code ~32KB can be removed when using this approach.
> 
> Not sure the benefits:
> Currently we have a compromise between a huge jar of options (lynx.cfg) for
> advanced and expetienced user, and a small menu-driven subset (we should not
> normaly looks into .lynxrc et all, it is a machine generated file).
> It is not possible (and not useful) to made all lynx.cfg options menu driven
> since that introduce more problems than it solves.

  I don't mean that we should make ALL options of lynx.cfg menu-editable - I
meant that options currently allowed in .lynxrc should be menu-editable -  so
no (possible) change should be made to option menu generation, etc. 

> just few points:
> - .lynxrc has options with other names when in lynx.cfg
> so we should add synonyms to provide compatibility, etc.
 IMO this is a main problem, but it can be solved.
> - we should restrict most lynx.cfg options for .lynxrc
 According to the syntax I propose, the allowed options are specified, not
disallowed. So the line that limit the allowed options for .lynxrc won't be
very long.

> - command line flags in between...
 This can be solved.

> >  In present state, users with paranoid sysadm were to live with colors s/he
> > specify.
> ??? what do you mean?
> with paranoid sysadmin you can get an opprtunity
> to have no opportunity et all.
> 
 And what do you mean?
 I meant the following: for lynx compiled without lss, colors are specified in 
lynx.cfg. Since it's not writable by user, each user have to use the colors
sysadm specified (same for viewers, keymaps...)

PS: And I don't insist on making .lynxrc to be included by lynx.cfg.

 Best regards,
  -Vlad


reply via email to

[Prev in Thread] Current Thread [Next in Thread]