[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
lynx-dev Config files (was Re: lynxrc 'problem')
From: |
Sinan Kaan Yerli |
Subject: |
lynx-dev Config files (was Re: lynxrc 'problem') |
Date: |
Sat, 29 Aug 1998 20:20:37 +0100 |
Before the subject get distracted or it fades away, I would like to
start a discussion on re-organising Lynx configuration files:
"userdefs.h, lynx.cfg, .lynxrc".
Problems/Difficulties:
* Repeated definitions which makes toggles misbehaving.
* Help of options/settings defined in an ordinary text file not in html
format (current one only explains the ones in the options page)
* which makes sizes of both lynx.cfg and .lynxrc big.
* Enabling/Disabling some options for captive accounts using lynx.cfg
Suggestions:
* Reading order of the config files
- Read lynx_disable.cfg file [if it exists]
- Read lynx_site.cfg file [if it exists]
<if anthing else left unset use the defaults from "userdefs.h">
- Read .lynxrc [if it exists]
_Ignore_ disabled ones.
- Read command line
Toggle/Set overrides all the above _if_ it is not disabled.
Most of the above order is already coded except 'lynx_disable.cfg'.
This is actually similiar to what pine uses: pine.conf.fixed,
pine.conf, .pinerc
Basicly if we can reorganise the order of option-reading we would end
up with lynx_site.cfg files having only several lines in it.
* One and only one decent HTML document for all the options:
- For example: In both lynxrc and lynx.cfg there is a list for
possible character sets. I think the following setting (regardless
of which file it is in) is enough to the direct anybody in the right
direction:
# CHARACTER_SET defines the display character set.
# Please refer to
# file://localhost/bla/bla/lynx_help/lynx_cfg.html#character_set
# for a full description and a complete list.
#CHARACTER_SET:ISO Latin 1
If you check the current one the above section is almost 100 lines.
Besides, it is repeated in .lynxrc. What a waste of disk and code
space.
- Basicly if we want people to read and change their options we should
give them _one_ document explaining _all_ possible options. Let's
not forget that config files can not be counted as help files for
a WWW browser.
- After the introduction of context sensitive UIPs we can even put help
points for certain items in Options Page.
* Another important point is that "who reads config files" and (not
or) "who changes them".
- If the lynx is in a multi-user environment it is almost certain that
users will find an already set 'lynx.cfg'. So users probably
wouldn't want to read but they want to change options; so they _can_
run lynx and _could_ reach lynx_help files (not config files) and
change them in .lynxrc (not in lynx.cfg).
- If the lynx is set badly; you want to change eveything. So grab
a working copy of .lynxrc (possibly from lynx.browser.org) and put
it in your home again start reading the help files (not config
files) for tuning.
- If lynx is run by a single user; one has to read the help files.
_and_ change everything (even the code itself) to your taste.
- Among the possible categories [a) don't read & change, b) don't read,
but want to change, c) want to read & change] we only have to think
about (b) and maybe (c).
Which is why I said we need only _one_ documentaion for all options.
Sinan.