[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
lynx-dev do we need userdefs.h & lynx.cfg ?
From: |
Philip Webb |
Subject: |
lynx-dev do we need userdefs.h & lynx.cfg ? |
Date: |
Sat, 27 Feb 1999 22:17:16 -0500 (EST) |
990227 Leonid Pauzner wrote:
> 27-Feb-99 06:53 Larry W. Virden wrote:
>> Is there a strategy for what parameters are put into $HOME/.lynxrc
>> versus only being in a lynx.cfg file?
>> On a single user system, the difference isn't that big a deal
>> the user can quit lynx, edit the file, and start back up again.
>> On _some_ multi-user systems, the user can copy the site lynx.cfg ,
>> edit it, and then start up with a command line argument.
>> On _closed_ multi-user systems, that's not an option.
> ^^^^^^^^
> on systems without a shell access there is no problem for users
> whether to deal with lynx.cfg or ~/.lynxrc - both are hidden.
> And with shell access you may include a local lynx.cfg copy
>> one criteria would be "is this a config option
>> a user might need/want to change during a specific executable session"
>> since the user has no way of changing this value during a session
>> unless the value is changable via the O option
>> and if it goes on that page, it probably should be storable
>> (on user request) into $HOME/.lynxrc .
> both criteria should give the same result (ideally) -
> values "that individual users might have a reason to change"
> should be available from O)ption menu
> and .lynxrc list should be a subset of O)ption list
> so we need not edit .lynxrc manually (unless someone want explicitely).
>> Another criteria would be "is this a value
>> individual users might have a reason to change".
>> values that might not change a lot, but still need to be stored per user.
>> email addresses, bookmark file names, etc. fall into this category.
this raises a question which came up last year with some discussion:
could we simplify configure/compile/cfg/-switch/Options to 2 lists?
ie (1) --switches would replace many configure & userdefs.h choices,
esp those to protect vs non-shell-user abuses
& those to reduce the size of the binary
or avoid other hardware problems, eg with NSL_FORK ;
(2) would replace choices in userdefs.h , lynx.cfg , -switches & Options
which all users might want to make for their personal purposes.
userdefs.h & lynx.cfg would disappear in their present form
& Options would expand to cover some lynx.cfg material,
its choices being recorded in .lynxrc ; -switches would be retained,
for use on special occasions or in a script. this would parallel Screen (eg).
would this require anything more than reorganising a lot of #ifdefs ?
yes, someone has to do it & it's a big job,
but the present set-up is inherited from earlier days
when Lynx just growed & no-one fully realised how complex it might become.
--
========================,,============================================
SUPPORT ___________//___, Philip Webb : address@hidden
ELECTRIC /] [] [] [] [] []| Centre for Urban & Community Studies
TRANSIT `-O----------O---' University of Toronto