Re: lynx-dev options unification

[Bela Lubkin]

Nelson Henry Eric wrote:

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

If by "smaller image" you are referring to the size of the executable,
forget it.  With my proposed unification, you would be saving something
like 1K of code space, and it would be a totally illusory savings.
Every Unix process has memory which holds a copy of its command-line
arguments.  You propose to replace 1K of file-opening-and-parsing code,
shared among all processes, with some large amount of *per-process*
command-line argument space.

1K is probably a bit on the high side.  If you still want .lynxrc
support, you've got all of the file processing code anyway; the only
code you'd be removing is "figure out the lynx.cfg name from
$LYNX_CFG_FILE, -cfg argument, or compiled-in default; pass that file to
the config file parser".

What might save a bit of space: a compilation option to omit all of the
deprecated entries in the option table, leaving only the final universal
names.  However, most of those savings could be gained by designing the
table to save space in the first place.  e.g. only one table entry per
option, with up to 4 (or however many we turn out to need) alternative
name strings; I think this would save a fair amount over having a
complete options table entry for each synonym.

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

Look at all the options in lynx.cfg.  This would be an administration
nightmare.  You don't want to have to edit 1000-character command lines
even if your editor handles them...

>Bela<