Re: lynx-dev Re: what to do about html help files.

[Bela Lubkin]

Henry Nelson wrote:

> > 4) Not yet fully implemented: reload the configuration files
> 
> Aren't you in a sense turning lynx.cfg into .lynxrc?  If we allow reloading
> of lynx.cfg, why not do away with it entirely and put everything onto the
> Option Menu?  (Comments, Bela?)

You'd have to go back and look up my old message, but here's my current
thinking about how it should all work:

We have far too many runtime configuration mechanisms.  There are
internal defaults (some compiled in from userdefs.h or config.h, others
are absolute Lynx defaults); a few environment variables; command-line
options; lynx.cfg and its included files; .lynxrc; two different options
menus; and a number of keyboard toggles (like '^V' -> SWITCH_DTD).

Several of these mechanisms are essentially similar -- parsing of
options from one place or another.  Except that the names of the options
vary.  We have the "-popup" command-line option, "USE_SELECT_POPUPS" in
lynx.cfg, and "select_popups" in .lynxrc.

A big part of my vision is to unify these things so that they are
synonyms, parsed by the same function, accepted in all places and forms.
The actual names would be stored in structures, as they are now, except
that each structure entry would have room for multiple strings.
Furthermore, all of the documentation would be changed to refer only to
one "preferred" name, except for a section that would explicitly
document the deprecated names.

So, for instance, we might have:

  struct LynxOption LYSelectPopups = {
    Active = USE_SELECT_POPUPS;   /* compiled-in default */
    Cfg = UNSPECIFIED;            /* from lynx.cfg or includes */
    Rc = UNSPECIFIED;             /* from .lynxrc or includes */
    CommandLine = UNSPECIFIED;    /* from command-line argument */
    User = UNSPECIFIED;           /* from options menu or kbd toggle */
    CommandLineAction = UNSET_ARG;/* not sure if this is needed... */
    Name1 = "popup";              /* preferred, was command-line */
    Name2 = "select_popups";      /* deprecated, was .lynxrc */
    Name3 = "use_select_popups";  /* deprecated, was lynx.cfg */
    Description = "toggles handling of single-choice SELECT options via\npopup 
windows or as lists of radio buttons";
    Security = USER;              /* user has complete control */
  }

Code that currently says "if (LYSelectPopups)" would instead say "if
(LYSelectPopups.Active)".

The functions that currently parse command line options, lynx.cfg,
.lynxrc, and the options menu would all call the same function, passing
only an indication of which field should be filled in: CommandLine, Cfg,
Rc, or User.  The parse function would first parse the option, then fill
in the specified field, then resolve the active value:

  if (option.Security >= USER && option.User != UNSPECIFIED)
    option.Active = option.User;
  else if (Option.Security >= RC && option.Rc != UNSPECIFIED)
    option.Active = option.Rc;
  else if (Option.Security >= COMMANDLINE && option.CommandLine != UNSPECIFIED)
    option.Active = option.CommandLine;
  else if (Option.Security >= CFG && option.Cfg != UNSPECIFIED)
    option.Active = option.Cfg;

This means that we always know where the active value came from,
according to the override chain.

The Security value helps prevent users from changing things that the
system administrator wants to lock down.

As to the parsing itself, I think it should accept all syntaxes
everywhere.  Command-line arguments are "-arg" or "--arg", optionally
followed by ":value" or "=value" or "+" or "-".  .lynxrc and lynx.cfg
options are generally "option:value".  So, in any of these places (and
really the parsing function doesn't know which place it's coming from
anyway), accept:

  [[-]-]arg[:value | =value | + | -]

(case would be ignored, so "-popup", "-POpuP+", "Use_Select_PopUps=1",
"select_POPUPS:TrUe" all acceptable.)

This also plays very nicely into the LYNXSETTINGSTATUS: scheme.

Doing this would involve a lot of changes all over the place (not least
of which is changing every reference from SomeOption to
SomeOption.Active).  The benefits would be: considerably less overall
code, in the end; less confusing restrictions on what can be set where;
less confusing multiple names for the same thing; easier future changes.

There would be a new "security" option, whose own default Security value
would be CFG.  e.g.:

  # only lynx.cfg can change the security of other options!
  security:security:cfg
  # only allow lynx.cfg to change whether cookies can be accepted
  security:cookies:cfg
  # users can choose whether searches are case-sensitive
  security:case:user

...

Wheee.

Lots of ideas, no bandwidth to implement them.

body.html etc. seem to be derivative works which could be
runtime-generated from 1) the complete table of options, including their
descriptive text and various values + 2) an external source of larger
commentary (e.g. mining them out of an unmodified lynx.cfg).  The larger
commentary could even be compiled into the binary, though that seems
wasteful and quite likely a maintenance nightmare.

Likewise the runtime options menu could be constructed out of the table
of options (and, in fact, I see no reason why the runtime options menu
needs to be a different entity from body.html/etc.)  Within the options
menu, if you want fuller explication of some option, you ask for it
(follow a link), which shows both the larger commentary and the override
chain of values.

(Thus, my example "struct LynxOption LYSelectPopups" really needs to be
"struct LynxOption LynxOptions[LYSelectPopups]" -- it needs to be an
array so it can be walked easily.  Then we need a macro for getting the
current value, because `LynxOptions[LYSelectPopups].Active' is
ridiculously long.  Maybe `LyOpt(LYSelectPopups)'.)

No reason to "do away" with .lynxrc.  It becomes just another place
options are collected from.  It differs in that it's owned by a
particular user, not the system (administrator).  We write it with a
particular syntax, for our convenience; we don't care if the user edits
it to a different one, as long as it's still valid, and if he ever saves
options at runtime, we'll write it in our syntax again.  It could start
out as a copy of a lynx.cfg (in which case many of its options will
probably be ignored because the user isn't allowed to change those
things).

>Bela<