Re: lynx-dev options unification

[Nelson Henry Eric]

> 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.

That's for sure!  And confusing, to say the least.

>   - 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
[...]
>   - 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
[...]
>   - In the end, there should be just one table of options, possibly

Would it be possible to do away completely with lynx.cfg?  (Keep the
mechanism in the code only for backward compatibility, but ifdef it all
out so that when a new lynx is installed, the installer can decide to
phase out the cfg file and be rewarded by getting a smaller image.)

My idea is to make sure there is a command-line switch for every "has
security implications" option, if that isn't true already . All other
"safe" options go into .lynxrc and/or the interactive options screen.
The disadvantage, I guess, would be the problem of having to have such a
long alias or batch file.

__Henry