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

[Henry Nelson]

> > future developers (in Vlad's sense) what configuration mechanisms are
> 
> (which was Vlad's sense?)

He may correct me, but I believe he meant "programmer," someone with the
ability to contribute to the c language portion of the source code.

> 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

Because of my clumsy way of expressing myself, my intent didn't carry
through, but this is what I'm talking about, simply "what-belongs-where."
It's like my *suggestion* about naming all cookies-related defines in
lynx.cfg with the same prefix.  I very clearly stated "it's too late now,
but, hey, what about next time."  If we start now, while something is in
its infancy, it can be done.  Once it's in the source, no one, including
the author in many cases, is willing to do anything about inconsistencies.
That's why I bark so loud when something isn't established; I guess I just
end up turning people off.

> 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 DO understand this.  I'm a bit of an idealist is all.  Another problem
I recognize with Lynx is the "too many cooks spoil the soup" one.

> Do we actually have a "proliferation of mechanisms for setting options"?
> That term seems to suggest that new mechanisms are being added all the

You are very correct; I am wrong.  My "gut feeling" (not good to listen
to such biased talk) is that the mechanisms are not too many _at the
present_, but that the recent trend has been to give ALL the mechanisms
control over EVERY feature.  In particular, I don't understand why every
feature must be represented on the O)ption Menu AND lynx.cfg.  Just
because the form-based O)ption Menu gives us the opportunity to put an
unlimited number of options on it doesn't mean we *have to* load it up.

[As a side note, the key-based O)ption Menu, could easily handle new
features if some of the, what I call, "general preference" options
were moved to lynx.cfg.]

> 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

I'll not repeat all of this, but this post needs to go into the docs/
subdirectory right along with your README.defines.  Maybe you can start
a README.developers file that would lay out some of the ground rules or
courtesies that source contributors should be encouraged to follow.  I'm
not saying you need to write anything special, just append posts like this
together.  It's a start in the right direction, IMVHO.

>   - form-based Options Menu as alternative interface

No particular gripe since the key-based O)ption Menu remains, but it
would be a shame to abuse and overload it.

>   - lynx.cfg can INCLUDE other lynx.cfgs

Not thrilled about it, but bow to the majority opinion.  (I admit I was
taken back a bit by Larry saying he wasn't using it, though.)

>   - LYNXCFG://reload

I am no fan of this one.  Probably just my fear of black boxes I don't
understand.  I'll just have to trust Leonid's judgment on this one.
With the reload mechanism, however, I think it should be possible to be
even more discriminatory on what goes on the form-based Options Menu.

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

Not a problem, but to me they seemed like a perfectly valid alternative
to the INCLUDE mechanism.  I know they are very different in what can be
done and the way they are used, but I think the INCLUDE feature would
have been precluded by judicious use of "special configuration files,"
IMalsoVHO.  Not in anyway attempting to start an argument, but if, for
example, there were a lynx.psrc, a rather large chunk of explanation
would not have been necessary in lynx.cfg.  Parsing of the configuration
options would be totally done in the prettysrc module, so those not wanting
it could compile it out without having a remnant in the distribution
lynx.cfg.  As it stands now, if someone were to use the html lynx.cfg,
they'd find an explanation of a feature they might not be able to turn on.
Not so with say lss.

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

I could only ask, too.  It seems that confusion about on/off toggles
has lessened, due either to improved handling or improved documentation.

> 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

An area that frustrates me sometimes with the forms-based O)ption Menu.
I haven't bothered to translate "options marked with (!) will not be saved"
-- yet.  Maybe it wouldn't raise the hair on the back of my neck if that
were: "Options marked with (*) can be saved by checking the Save Options
box at the bottom of the Options Menu."  And put it at the bottom of the
page.  Right now the top half of the first page of the form-based Options
Menu is filled with duplicated links and irritating remarks.  Oh, well.

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

I think you have done a great service to Lynx development just by lending
your expertise to outlining the configuration mechanisms that exist.

__Henry