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

[Klaus Weide]

On Sat, 18 Dec 1999, Henry Nelson wrote:

> I rather resent the word "sneak."  I have been expressing my concern for

I regret having used that word, it was no warranted.

> 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

I don't think your concerns are Bela's concerns.

To summarize his, from that thread:
|   We have far too many runtime configuration mechanisms. [...]
|   Several of these mechanisms are essentially similar -- parsing of
|   options from one place or another. [...]
|   A big part of my vision is to unify these things so that they are
|   synonyms, parsed by the same function, accepted in all places and forms.

|   No reason to "do away" with .lynxrc.  It becomes just another place
|   options are collected from.

Bela was interested in changing the *internals* (a unified mechanism).  *Not*
in reducing the number of configuaration mechanisms visible to the user.  I
think that much is quite clear from
   <http://www.flora.org/lynx-dev/html/month0699/msg00029.html>.

As benefits of his somewhat concrete code change ideas, he lists:

| The benefits would be: considerably less overall
| code, in the end; less confusing restrictions on what can be set where;
| less confusing multiple names for the same thing; easier future changes.

There is no mention of "less places where the same thing can be set".

And it becomes even more clear at the beginning of
  <http://www.flora.org/lynx-dev/html/month0699/msg00040.html>:
|                      I didn't mean that we should get rid of these
| external manifestations, but rather that we have too many
| *implementations* of configuration mechanisms.  I propose to keep all
| the same externals, but replace the internals with a single unified
| system.

I am sorry, but I have to admit that, after all your "expressing
concern", I still, or again, don't know just what exactly your concerns
are.  That is probably my fault, blame me for not paying attention.  Is
it confusion to users you want to eliminate, or inconvenience to
yourself, or "kbytes of code", or something else.  What is the driving
motivation?  It just doesn't seem to be the same as Bela's.  Maybe you
could point me to some sort of summary, even if yhou think I should
have "got it" by now.

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

You know that I didn't really request such a patch from you, that my
imperative what rhetorical.

I was trying to point out that for consistency, if you find
"duplication" of the new thing under discussion bad, then you should
disagree with the majority of options on the Options Menu.  If you don't
send a patch yourself, you should welcome someone else sending one, to get
rid of the  "duplicated" Show Cursor, User Mode, etc., etc.

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

We agree.  I don't like the tree design.  I don't want to see it.  Ever.
Unless, and until, I change my mind, at which point I would do something
to turn it on.  Until that point comes, I should *not* have to do anything
to turn this thing off.  Nor should anybody else.

Where we might disagree is whether that popup on the V.Links page itself
is acceptable; personally I don't mind it to much *if at least it would
work, and if it doesn't force a "tree view" on me*.

So we both want the thing "off".  For ourselves.  By default.
I do *not* see what this has to do with the question: where can it (the
"style") be changed.


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

You may have suggested that, and multiple times at that.  But I don't see
a consensus (not even a developing one) for changing in your direction.
(I'm quite sure tgat I wouldn't support it.)  In fact, your position seems
very extremist to me - if you really want to be consistent with it, see
below.

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

In which important way are those two different from the majority?  

If the criterium for being "allowed" on the Options Menu were: "likely
to be changed often at run-time" - then nearly *nothing* belongs on the
Options Menu.

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

Maybe.  I can see it for (assumed) character set of document, but not even
for Display Character Set.  The latter certainly isn't expected to change
at all, normally (once you've found the right one) - much less with
"considerable frequency".  Well, exceptions for a small minority of Linux
--enable-font-switch users.

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

Where do you get this from?  There was no coding error, there simply was
no attempt at all to have the setting saved in .lynxrc.

The only accident, really, was that the popup on the V.L.P. itself worked
(and is working) at all, at least sometimes.

Henry:
> > > > Why the need for all the duplication?  PLEASE DON'T add a lynx.cfg 
> > > > option if
> > > > you're not willing to remove the .lynxrc one.
Vlad:
> > > It should be saved somewhere,
> > > and I don't insist on lynx.cfg at all.
Henry:
> > Whew!  Glad to hear that.
[me, kw:]
> > 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?).  

No matter your original suggestion - here you seem to have changed
your mind.  If it's okay for you to not have a lynx.cfg option if
there already is a .lynxrc option - if you're even ASKING for NOT
adding a lynx.cfg option - then you most definitely do NOT agree with
me "as far as lynx.cfg".  Either that, or you have changed your mind.

*Above* (quoted "> > > >") you seem to be saying it's fine with you if
V.L.P.-trees cannot be turned off in lynx.cfg, as long as it can be
turned off "somewhere".  Well perhaps it wouldn't be your preference -
you may prefer lynx.cfg - but better being able to turn it off in one
place than in two.  Did I get that wrong?

A am baffled by this, given that you seem just as annoyed with the tree
display as I am.  Maybe you do not realize what you are asking for.
I believe what you ask for implies that users of lynx compiled with
--disable-forms-options cannot change the damn V.L.P. style at all!
Well, or I do not realize what you are asking for.

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

You have some nerve, declaring a whole user population as a dead breed.
May their ghosts haunt you...

I thought you were still offering some setup like that yourself.  Apparently
not any more.

I think you *are* misunderstanding.  There were always plenty of people
able to run Lynx without "public access" restrictions.  Those people
always could edit lynx.cfg.  As a generalization, "people" never depended.
Some did.  Some still do.  Their numbers may be declining, so what?
I don't know what *exactly* you meana with a "public access system".  But
it it's the regular "anonymous" setup - those normally don't write .lynxrc
at all, and then there is no good reason for reading it either, as long
as the .lynxrc settings just "duplicate" defaults in lynx.cfg.

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

And I would think that a vast number of Lynx users (whether on this
list or not) do not know about either lynx.cfg or include files or a
.lynxrc file.  The preference/configuration mechanism that is "built
into the interface" (for example, it shows up in the Novice Mode help
lines) is the 'O'ptions Menu.  That's the one that most users are going
to know about if they know about anything.

'O'ptions Menu settings are stored in .lynxrc.  They are not stored in
lynx.cfg (and Lynx better NOT start messing with the lynx.cfg file itself,
IMNSHO).  As long as you are not changing these fundamentals, storing
user preferences in .lynxrc is necessary if you want to allow changing them
at all, with effect lasting beyond the session, from any sort of menu.


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

1) It is not quite ready for prime time.
2) LYNXCFG://reload does not provide a menu-like choice, popup options, etc.
   *You have to edit a lynx.cfg file*.
   You and I can do without those niceties, and can edit our lynx.cfg files.
   (although I do find selecting some things from a popup list more convenient
   than typing in corresponding strings, for example, for example for
   CHARACTER_SET.)
   I don't think I am assuming too much when I say "The Options Menu is a more
   appropriate interface for most users, at least at the beginning".

> so really it's becoming
> another .lynxrc file in the sense of run-time options.

There is that trend, yes.

Is it a good trend, that more and more run-time options do NOT have an
easy interface (Options menu)?

So far it only affects
  - somewhat advanced users,
  - willing to experiment,
and I don't see that changing soon.


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

I really don't know why you repeatedly bring up MSIE.  It doesn't
clarify your point, at least for me.

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

Is anybody suggesting to put more "layers of windows" (or of screens)
between the user and anything?

It seems *you* are suggesting that, when you suggest that some things
should be configuarable only in one place and others only in another
place.


Well I have some nagging feeling that somehow, somewhere, I must have
completely misunderstood you.  If so, *please* clarify.

   Klaus