[Top][All Lists]

[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: Philip Webb
Subject: Re: lynx-dev extending the syntax of 'include' command in lynx.cfg
Date: Thu, 15 Apr 1999 01:10:19 -0400 (EDT)

990414 Vlad Harchev wrote: 
> On Wed, 14 Apr 1999, Leonid Pauzner wrote:
>> 14-Apr-99 03:24 Vlad Harchev wrote:
>>> More brave approach:
>>> Make ~/.lynxrc 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.
>>> with LP's patch, lynx.cfg can be edited at runtime and reloaded
-- snip --
>> Currently we have a compromise between a huge jar of options (lynx.cfg)
>> for advanced user and a small menu-driven subset (we should not normally
>> looks into .lynxrc at all, it is a machine generated file).
>> It is not possible or 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 options currently allowed in .lynxrc should be menu-editable -
> so no (possible) change should be made to option menu generation, etc. 
>> .lynxrc has options with other names when in lynx.cfg,
>> so we should add synonyms to provide compatibility, etc.
> this is a main problem, but it can be solved.
>> we should restrict most lynx.cfg options for .lynxrc
> According to syntax I propose, 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.
> 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.
i hesitate to join your erudite discussion,
but there is a strong long-term case for the bravest choice:
uniting  lynx.cfg , .lynxrc/Options  &  -flags  into  1  set of choices
& moving security items & those without which Lynx won't start
into  userdefs.h + --configureflags .
perhaps your current work is a step in that direction.

SUPPORT     ___________//___,  Philip Webb : address@hidden
ELECTRIC   /] [] [] [] [] []|  Centre for Urban & Community Studies
TRANSIT    `-O----------O---'  University of Toronto

reply via email to

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