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

[Henry Nelson]

> Adding options for the same setting to lynx.cfg AND the Options Menu (.lynxrc)
> is NOT duplication that should be avoided.
> 
> At least, it hasn't been considered like that, so far.
> 
> Henry, are you trying to sneak in some kind of new policy here??

I rather resent the word "sneak."  I have been expressing my concern for
what I consider "unnecessary proliferation" of options and mechanisms
for setting them for over two years now.  There is at least one other
person concerned, Bela Lubkin:

http://www.flora.org/lynx-dev/html/month0699/msg00040.html
http://www.flora.org/lynx-dev/html/month0699/msg00029.html

> Then be consistent, and send patches to remove "Show Cursor" from either

No.  The reason is quite simple, and I do not believe selfish.  Almost
all of the options that have been "duplicated" in lynx.cfg and .lynxrc
are for "features" which I can do without.  Those which are not off by
default, I simply don't compile in.  Why should _I_ be the one to polish
up stuff that I don't use and would not have added to Lynx in the first
place were it my *policy* to set.

The present example is perfect.  I don't like the tree design; I like a
compact style with the links beginning one or two spaces indented from the
left, leaving 78 (39 kanji) characters.  Now _I_ have to go to the Option
Menu and change it -- on the 3 or 4 machines that I use Lynx on.

And while I'm ranting, let's keep Vlad happy, too.  _I_'m not a developer.
There's not a person on this list who doesn't know I couldn't do the coding
necessary to make the patch you request.

> for "User Mode", same for the majority of options in the Options Menu.

It's not as if I haven't suggested such a change and _reevaluation_.  My
concept has been, perhaps misguided, that the Options Menu was for changing
things that one would with considerable frequency be changing run-time.
Although I would agree with moving "User Mode" and "Show Cursor" to lynx.cfg,
I do not propose moving the "majority of options."  If it comes to that,
then it is time to get rid of one or the other.  Things like character
set of display and document are very appropriate to have on the Options Menu.

> >  As other say, no .lynxrc option exists for it.

_But_ the intent to have a .lynxrc option was there, it just was some
error in coding that prevented it from working.

    It should be saved somewhere,
> > and I don't insist on lynx.cfg at all.
> 
> But I do.

As far as lynx.cfg, I agree (Are you forgetting that _I_ was the one who
suggested putting VLP-style control in lynx.cfg in the first place?).  I do
not agree with having it in both lynx.cfg and .lynxrc.

Why do we have both lynx.cfg and .lynxrc?  Maybe it's my misunderstanding,
but it seems to me to be a relic from the days when people depended on
Lynx operating on a public access system.  Users could not change any option
except for what was offered on the Option Menu (which had to be initialized
somehow, thus .lynxrc).  Such users are a dying, if not dead breed.

Nearly 100% of the posters on this list at least use Lynx from a shell
account or, a growing number, on PCs or workstations.  This vast majority
has access to lynx.cfg and any number of include files, and a .lynxrc that
they can save to.  The only advantage that .lynxrc has offered is that options
on it can be changed within a session, i.e., without having to restart Lynx.
It seems now that lynx.cfg options can be reloaded, so really it's becoming
another .lynxrc file in the sense of run-time options.

I'll stop here.  Others will have to carry the ball.  I am not the one
piling straw on this camel's back.  MSIE is a click away for me these days.
One thing I don't like in any software is having to click down 4 or 5
layers of windows to get to the information I want.  If I can see things on
one screen and keep my fingers on the keyboard, I'm happy.

__Henry