[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
lynx-dev options unification
lynx-dev options unification
Tue, 6 Oct 1998 04:25:17 -0700
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:
CHARACTER_SET:ISO Latin 1
character_set=ISO Latin 1
no flag for user mode
no flag for display char set
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'
- 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...
Re: lynx-dev options unification, Nelson Henry Eric, 1998/10/07
Re: lynx-dev options unification, Lloyd G. Rasmussen, 1998/10/07
Re: lynx-dev options unification, David Combs, 1998/10/10