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

[Klaus Weide]

On Mon, 20 Dec 1999, Henry Nelson wrote:

[About BL's concerns]
> > To summarize his, from that thread:
> > |   We have far too many runtime configuration mechanisms. [...]
>               ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> To me, "proliferation of mechanisms for setting options" is essentially
> the same thing.
> 
> > Bela was interested in changing the *internals* (a unified mechanism).  
> > *Not*
> > in reducing the number of configuaration mechanisms visible to the user.  I
> 
> So am I.  If there are to be multiple mechanisms, HOWEVER, I would like to
> see more advantage being taken of the strong/weak areas of those mechanisms.

That is very reasonable, how could anyone disagree? :)


> > Is it confusion to users you want to eliminate
> 
> Exactly.  Clearing up the "internals," making it clearer to present and
> future developers (in Vlad's sense) what configuration mechanisms are

(which was Vlad's sense?)

> available to him/her, what their respective advantages and purposes are,
> and how the mechanisms interact with each other, will reflect itself in
> the "externals," and lead the way to a rational and user-friendly interface.

"Clearing up" the internals, in the way envisioned by Bela, seems like a
huge undertaking.  A radical redesign.  Not that it's impossible.  But
based on experience, considering the history of other Great Ideas and all,
I regard this as another pie-in-the-sky thing until I see it happening.

It's safer to assume that that thing is not going to happen, or not
anytime soon.  If the interface needs to become more rational and
user-friendly - well, someone (as usual :) ) needs to work on that.  And
if we are just talking about what-belongs-where, at least - it *can* be
done now, without the Great Restructuring & Unification as a precondition.
It may just be a bit more work, require a bit more awareness by
contributors (or, should they not care, vigilance by you and everyone who
*does* care :) ).  If features get in with inconsistent or illogical
configuration - well that reflects the degree of importance that
lynx-dev'ers in general accord to these issues.

Besides, the belief that clearing up the internals "will reflect
itself" etc. and automatically lead to a better interface reflects a
belief in technological solutions that I cannot share...  I know you
didn't say that, especially not the "automatically", but I detect the
tendency.  If the bigger problem is that the people who do contribute[*]
code don't really care all that much about a consistent interface - not
enough to spend the time -, then simplifying internal mechanisms won't
just rectify the situation (it may help, of course).

[*] I don't exclude myself.

Do we actually have a "proliferation of mechanisms for setting options"?
That term seems to suggest that new mechanisms are being added all the
time.  I don't really see that happening all that much.  But maybe we
disagree on what counts as different "mechanisms", so let me try to
list what IMO counts as that (and some of their changes), in somewhat
chronological order:
  - userdefs.h                                  - ancient
  - lynx.cfg                                    - ancient
  - (key-based) Options Menu, saving to .lynxrc - ancient
  - command line options                        - ancient
  - some environment variables                  - ancient
          (all 5 mentioned before "RELEASE of Lynx 2.1" in CHANGES files)
  - extra definitions in Makefiles (-DFOO) or buid scripts
                                     - can be assumed as least as ancient
  - (and for completeness, let's list direct tweaking of the source, too.)

  ...time passes...

  - ./configure introduced.  Starts replacing Makefiles definition.
  - ./configure flags start setting/replacing some userdefs.h options.
  - command line option syntax enhanced: -foo_bar+, -foo_bar-,
              -foo_bar=on, -foo_bar=off, --foo_bar, --foo-bar, ...
                                        (not all at the same time)
      [btw: still bugs, still not completed IMO; cf. -show_cursor=on/off]
  - form-based Options Menu as alternative interface
  - lynx.cfg can INCLUDE other lynx.cfgs
  - LYNXCFG://reload

Did I miss anything significant?
(There are some special configuration files for special features -
like .lynx-keymaps, lynx.lss, cernrules - I don't think they are
generally a problem in this context.)

Does this look like a continuing proliferation?  Maybe...  having compiled
this list, it looks quite a lot (more that I'd thought).   But consider
the time frames, and consider how much of it really is old, and how the
newer entries are mostly variations/additions in functionality and not
completely new.

Anyway...  I think the "number of mechanisms" itself isn't really the
problem at all.  After all, as long as a mechanism just "exists", but
you don't know about it, don't need it, and nobody tells you to use
it, it might as well not be there - it certainly won't confuse you.
("You" = as a user or as an installer or an admin, whatever is the case.)
Additional mechanisms (that you don't need) are just implemented, for
those others who need it, and for you in case you discover them and
find them useful.

Problems come in when you *need* to use different mechanisms for
different (but similar) things, and don't know which one to use.  When
documentation points to different mechanisms without guidance, or in
an unclear way.  Or if they interact in some obscure manner.  (How
much is this the case?)

Problems also come in when things that *seem to be* equivalent (using,
apparently, the same mechanism), and can be expected to act in a
parallel manner, don't.  E.g., options in the O.M. that don't get
saved, when most options do get saved; or options in lynx.cfg that
cannot be updated by LYNXCFG://reload, when most options can be
changed.

Hmm, "just some thoughts".  Where do they lead, if anywhere, I don't
know.

--- Well this is getting too long already.  I'll reply to some other
pieces separately.

   Klaus