[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