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

[Mike Castle]

On Thu, Jun 03, 1999 at 01:01:02AM -0700, Bela Lubkin wrote:
> 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:

I have also made some comments on this subject back in November and February
(see:
http://www.flora.org/lynx-dev/html/month1198/msg00736.html,
http://www.flora.org/lynx-dev/html/month1198/msg00747.html,
http://www.flora.org/lynx-dev/html/month1198/msg00753.html,
http://www.flora.org/lynx-dev/html/month0299/msg01078.html,
http://www.flora.org/lynx-dev/html/month0399/msg00466.html).

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

I originally thought about keeping backwards compatibility with the current
lynx.cfg and command line options.  However, I honestly think that trying
to do that would be more troublesome than it's worth.  Instead, I think one
string should be used, and it used in all locations (command line options,
lynxrc, lynx.cfg, and even internal names used in the forms option code).
Instead, provide some external tools.  Filters to convert old lynx.cfg to
new format and wrapper script to provide backwards compatibility to old
command line if they want it.

By having lynxrc and lynx.cfg in the same format, we could reduce code
even further.

In the example below, I would suggest only having "popup" and the command
line would be "--popup=yes" or "--popup=on" or "--popup=true". Then
lynxrc and lynx.cfg would have "popup=yes" or "popup=on", etc.  The exact
same parser would be used (just pass the string sans --) without having 
to know where it came from.

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

Another idea might be, insted of using (LYSelectPopups.Active), use
(LYOptionGetBool(LYSelectPopups)) and then determine which to use.
The overhead of a function call isn't that great (I use this method in
an app that pulls this info out of Win32 registry and you don't see a
performance difference, moreover, instead of the struct itself, I use
a handle that represents the structure which is local only to a single
file; so you have that extra layer of lookup ).  The benefit of this
is, you can *offer* the ability to, every time an option is queried,
stat the config files and if they've changed (say you changed options
in another window), make those changes active immediately.

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

The precedence is already there.  The current comments that get save with
lynxrc are already built into the exectuble.  Also, if Description was 
not set until run time (as in, like the first command), they could be set
with gettext() and offer language specific help.

> (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)'.)

Ohhh.... I should have read more before I wrote.  The thing is, not
everything is an integer.  There whould have to be different ones for
ints, booleans (I would recommend treating them different from ints), 
and strings (at work, our api also has char and doubles as explicit
configuration types; not sure those are needed here).

Another thing to consider my be associated arrays (ala awk and perl).
Instead of having separate items for each of the various colors (normal
fg, normal bg, bold fg, bold bg, italic fg, italic bg, emphasis fg,
emphasis bg, etc), we have one item (COLOR), and an association for it
("NormalFG", "NormalBG", "BoldFG", "BoldBG", etc).  Of course, the
heirarchial nature of the Win32 registry made this a breeze to implement,
and it did have the benefit of organizing things a little bit nicer in
the registry.   It might be tougher to implement here though.

The big win was not for things that were fairly hard coded (like colors), 
but instead, items that can grow.  A good example in the lynx would would
be printer and downloader configurations.

printer=Computer Center Printer:lpr -Pccprt %s
printer=Mail to Joe:(some mail to Joe command here)

The problem is providing the facility to handle anonymous options 
different from standard.  Rather than trying to add more things onto 
printer, for instance, have a separate item:

printer_secured:Computer Center Printer:TRUE
printer_secured:Mail to Joe:FALSE

Of course, those would only make sense in lynx.cfg (though I suppose
someone could do a printer_secured:FALSE and if they run lynx -noprint
themselves then they can't print).

Someone else brought up the problems associated with saving the rc file:
saving everything or just deltas.  That itself could be an option. 

-- 
       Mike Castle       Life is like a clock:  You can work constantly
  address@hidden  and be right all the time, or not work at all
www.netcom.com/~dalgoda/ and be right at least twice a day.  -- mrc
    We are all of us living in the shadow of Manhattan.  -- Watchmen