Re: lynx.cfg AND/OR .lynxrc [was: Re: lynx-dev lynx2.8.3dev.17

[Klaus Weide]

[ Only replying to this bit, since I happened to find the archive
reference ]

On Mon, 20 Dec 1999, Henry Nelson wrote:
> I offer an anonymous access Lynx, but VERY restricted [...]  I do
> not trust the forms-based Option Menu.  (Sorry.)  All a user can change on
> that Lynx offering is what is on the key-based Option Menu.

No need to be sorry - I think you are very right.  *At least* up
to now.  A scheme for configuration that uses interfaces that *can*
be accessed "from outside" (files; URLs), like the form-based Option
implementation, just *is* more dangerous than a custom-made module
without "programmable" interface, like the old Options code.

It's not the original form-based O.M.'s contributor's fault, he did
warn us:
  <http://www.flora.org/lynx-dev/html/month0898/msg00876.html>

I certainly may have missed it, but it seems Mike's concerns have
never really been addressed, they just kind of got forgotten.

Also, here is the original patch:
  <http://www.flora.org/lynx-dev/html/month0798/msg00510.html>
Some of the author's remarks are probably still relevant (but
I just skimmed them now).

I don't expect that new configuration options that get added to the
form-based O.M. will also be added to the key-based O.M. (except maybe
some exceptionally important one).  There isn't enough space in the
k-b.O.M., that was the major problem to begin with.  But things should
be kept working, so that lynx with only the old O.M. compiled in
remains usable, as much as possible.  Users of such a lynx may miss
new options on their 'O' screen, but those new options should still be
configurable elsewhere (lynx.cfg) and/or have sane/conservative
defaults.  (Preferably "and", of course.)  That isn't the case with
the new V.Links style selection, so far.

   Klaus