[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
lynx-dev simplifying configure/options (was multiuser)
From: |
Philip Webb |
Subject: |
lynx-dev simplifying configure/options (was multiuser) |
Date: |
Fri, 12 Mar 1999 13:20:34 -0500 (EST) |
990310 Mike Castle wrote:
> Leonid Pauzner said:
>> 28-Feb-99 14:16 Mike Castle wrote:
>>> I want to work on a new configuration mechanism for lynx.
>> This require a memory for command line switches
>> (and we could not change most of them on-line, yes?).
>> Now we have in that order:
>> read_cfg();
>> read_rc();
>> <misc code for handling command line switches>
> I pictured that, when active, there would be a heirarchy of config
> settings: those read from system config file, those read from personal
> config file, those from command line, those changed at run time.
-- grand redesign snipped --
before everyone gets carried away, could we return to the more basic issue
how to simplify the whole business of --configureswitches , userdefs.h ,
lynx.cfg , -execswitches & `O'ptions (did i forget one)?
Screen has just 2 levels of choice, (1) at compile-time
& (2) at/during run-time (controlled by .screenrc & :commands ).
can we not start to reduce Lynx choices to a similar arrangement, ie
(1) --configures + (most) userdefs.h + (some) lynx.cfg + (some) -execs ,
(2) (some) userdefs.h + (most) lynx.cfg + (most) -execs + `O'ptions ?
this has been suggested before & the first step is to decide
which features belong in (1) & (2), partly depending on security;
the `O'ptions form would expand & most choices would have -execswitches .
i'm willing to try to sort out the 2 lists to get started,
but some prior feedback on desirability/feasibility would help.
--
========================,,============================================
SUPPORT ___________//___, Philip Webb : address@hidden
ELECTRIC /] [] [] [] [] []| Centre for Urban & Community Studies
TRANSIT `-O----------O---' University of Toronto