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:
>   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 */
>   }

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


Oh, something I forgot to mention.

LyOpt should definitely NOT be a macro.

If LYSelectPopups is a #define or, better yet, an enum, then you have to
be especially careful about making sure both tables are in the same order.
Review the problems not long ago about the keymap stuff.  If if one gets
#ifdefed out, and the other doesn't, and things get all out of sync....

Instead, I suggest the following:

And enum LyOptE (someone come up with a better name, please) that would
contain the identifiers like LYSelectPopups (actually, I'd suggest
LYOpt* for all of the names).

Then, add a field to LynxOption  of type "enum LyOptE" and give it the 
name LYOptHandle, and give it a value of the the enumerated type (in this
case LYSelectPopups or LYOptPopups).

Then, the function LyOpt would scan the array of LynxOption structures
looking for the one the matching value.

Again, this is something that I do at work, and you don't notice any
performance change.  If it was noticed to be a performance hog, the array 
could be processed once into a tree of some sort and looked up that way.

The reason I think this is a better solution is that the maintenance of
such a table and list of enums is much easier.  You don't have to worry if
one is #ifdeffed out and the other isn't, nor do you have to worry about
them being in the exact same order.

Hmmm.... though, if, instead of using enums, strings were used, other
things could be improved as well.

When processing options from config files and command lines, we have to
look up by name anyway.  We could do the same for the back end processing
of the forms options menu.  It could literally be reduced to something
looping over the posted data and calling the config parsing engine (though
that would mean moving the current validation code to prevent someone from 
changing runtime values when they're not allowed from there to inside the
options parser, but we'd have to do that anyway for the other items; I
don't consider that a big deal).

So, one way this could work would be:

In an appropriate .h file:

extern char * LyOptPopups;

Then, in the appropriate .c file:

/* I admit it, I don't know how to use consts.  What would be appropriate
here if you don't want either the pointer to change or the string? */

char * LyOptPopups = "popups";

.....

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... */
     Name = LyOptPopups;           /* preferred, was command-line */


Then, of course, we should definitely build a tree keyed off of Name.
(does libwww offer anything handy?).

The point for using extern char * as opposed to a define is that the
contents of the string would only be used once in the executable rather
and at least once per module and possibly more (if compiler doesn't support
merging strings).

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