lynx-dev simplifying configure/options (was multiuser)

[Philip Webb]

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