lynx-dev Config files (was Re: lynxrc 'problem')

[Sinan Kaan Yerli]

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.