lynx-dev options unification

[Bela Lubkin]

Some development ideas for 2.8.2, 2.9 or even 3.0.

Currently, options can be set in many different venues: in the source;
with command-line flags; in a lynx.cfg file; in a .lynxrc; or
interactively from one of the two options menus.

What a mess.

lynx.cfg vs. .lynxrc is the worst of it.  We've got two different ASCII
options files which control partially-overlapping subsets of the
options.  When the same option is controlled by both files, the name and
format is different.  Command-line flags have yet a third name and
format.  A few examples:

  lynx.cfg:

    DEFAULT_USER_MODE:NOVICE
    CASE_SENSITIVE_ALWAYS_ON:FALSE
    CHARACTER_SET:ISO Latin 1
    VI_KEYS_ALWAYS_ON:FALSE

  .lynxrc:

    user_mode=ADVANCED
    case_sensitive_searching=off
    character_set=ISO Latin 1
    vi_keys=on

  command-line flags:

    no flag for user mode
    -case
    no flag for display char set
    -vikeys

These should be unified.  What I propose is:

  - Reduce to one option file parser.

  - Accept both "old" sets of options.

  - This includes understanding both ":" and "=" for `assignment'.

  - In each case, we choose a "preferred" option name and use it in all
    documentation; in the code that writes .lynxrc from the options
    menu; and in the distributed lynx.cfg.

  - The "other" option name becomes a deprecated name, still recognized
    but not documented (?maybe documented as deprecated?).

  - The parser knows whether it is reading a .lynxrc or a lynx.cfg.
    Options which have security implications can be set only from a
    lynx.cfg.  "Has security implications" would be a flag in the option
    structure.  Initially, we would give this flag to all options which
    today can only be set from lynx.cfg.  Later, it could be cleared
    from some of them on a case-by-case basis.

  - This still allows a user to set lynx.cfg options, by using the
    "-cfg" command-line flag or LYNX_CFG_FILE environment variable.  The
    presumption is that if the user is allowed command-line access, he's
    allowed anything Lynx can do.

  - To whatever extent possible, also unify the command-line flags with
    this scheme.  This might entail adding a third synonym for some
    options (for backwards compatibility); and perhaps more `assignment'
    separators.

  - In the end, there should be just one table of options, possibly with
    flag bits detailing which venues (command-line, lynx.cfg, .lynxrc)
    they're allowed from.  It seems to me that security implications are
    the only reason to remove options from a venue, and then only from
    .lynxrc, so I only see the need for one bit.  Some options might be
    *silly* from the command line ("lynx -include my.lynx.cfg") -- but
    even as I write that it's silly, I'm thinking of lots of possible
    uses for it!

  - It might eventually be possible to embed in the *same table* the
    underpinnings of the interactive options form.  e.g. a flag whether
    this setting should appear, strings to control its presentation, and
    a function pointer to parse the results (which could also be the
    parser for the other venues).

6 months ago, this kind of clean-up would have been unthinkable.  Now
that we have table-driven option parsing, we're a lot closer.

The potential benefits should be obvious...

>Bela<