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

[Henry Nelson]

> > 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. [...]
              ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
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.

> | code, in the end; less confusing restrictions on what can be set where;
> | less confusing multiple names for the same thing; easier future changes.
[...]
> | 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.
[...]
> 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
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.

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

I don't like the popup because it "steals" two lines from my screen.  (I
do not buy Vlad's argument because I seldom view more than 20 pages in
one session.  If I am "lucky" they will all fit on one page.)  I also don't
like it because my preference for a compact style is pretty much set in
concrete, and it most certainly is not something I am going to be changing
every time I run Lynx or go to the VLP.

But it seems I misunderstood the underlying intent of the popup, which is
causing the confusion.  See below with regard to saving to .lynxrc.

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

Well, if you want it "off," I _assumed_ that the author of the "feature,"
intended for the user to set the "style" to a non-tree one.  It seems
my assumption was incorrect, and the cause of all this confusion.  If this
were the case, then "where" the "style" is to be changed becomes important.

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

This question gets at the crux of what I have been trying to say.  If there
is no difference between what is set in .lynxrc and what is set in lynx.cfg,
or on the command line or compile options, then why do we need these four
mechanisms?  I am saying let's try and come up with a sorta consensus about
what goes where.  I have no gripe with offering multiple offerings of methods
for configuring a single feature, but I do have problems with blanket
duplication of features through all of the configuration methods.  If a
feature is best controlled by lynx.cfg, put it there.  If it is best
controlled on the Option Menu, put it there.  If it is best controlled by
both, put it on both.

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

:)

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

This is why there needs to be dialogue on lynx-dev.  Being able to change
the DCS is important for me because it is not easy to change between EUC/
SJIS on some of my terminal emulations.  I do some switching of "setterm -x"
according to IP of individual PCs, but sometimes I forget, or temporarily
want to transmit a code of the other set but still have Lynx sane.  I am
NOT saying that I know what other people need or want.  I am saying why
not have some policy as to what _kind_ of options are changed _where/how_.

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

Okay, this was where all the confusion started I think.  Totally my mistake.
Sorry.  I couldn't believe anyone would offer a feature without some way to
_either_ not compile it in leaving the default, former behavior (NOT to save
xxx kbytes; where does this equation to me and 1kb come from anyway?), _or_
permanently save the user's preference.  I couldn't believe anyone would
consider integrating a feature without some way to configure it.  Also, I
saw this entry in CHANGES,

+ now check directly in postoptions() whether the loaded document is one from
  which submission of option changes can be accepted, using the new tracking
  mechanism.  Only the form-based Options Menu and Visited Links are allowed.

which I mistakenly took to mean that the popup choice of styles was going
to be posted to .lynxrc.

I guess off-topic, but why is Visited Links allowed to submit option changes?
Why can't, or why shouldn't we limit that to the forms-based Options Page
alone?

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

Is there something wrong with this?  Why in the world do we want more than
one place to turn it off?  Maybe I don't know what I am asking for, but I
can't see the sense in having multiple methods to turn off a feature of
such marginal utility.  We're not talking about cookies or the ability to
access some web page, i.e., something central to Lynx's performance on the
Internet.

I'm saying 1) give me a way to --disable it at compile time and/or (both
is okay and preferred, it seems by me alone) an entry in lynx.cfg.  If the
author does it in lynx.cfg, 2) please do it right.  No thank you to five
defines: VLP_Sort_By_First_Visited,VLP_Reverse_Sort_By_First_Visited,
VLP_View_As_Visit_Tree,VLP_Sort_By_Last_Visited,VLP_Reverse_Sort_By_Last_
Visited.  Let's have something like: VISITED_PAGE:LIST*,TREE.  3) Don't
start a precedent for turning off features on individual pages they
generate -- keep configuration centralized by already implemented methods.

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

Their Lynx2.3's and Lynx 2.4's already are haunting _them_.

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

I offer an anonymous access Lynx, but VERY restricted since the attempted
break-in to my machine, and the actual break-in to the LAN at the University
causing considerable damage (lost data) to a number of the servers.  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.  Usage has
dropped to less than one session/2 months anyway.  I seem to have one steady
"customer" in Japan; that's it.  I do offer a way to contact the maintainer.

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

I was all wet here.  I was confusing changing options on the Options Menu
with having a .lynxrc.  Sorry.

> 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

This is an area where I suspect we differ in opinion.  I tend to want to
keep on 'O'ptions Menu only those things which don't have a hard key toggle,
but which someone may want to change runtime.  This requires perhaps that
all/most settings in the _distribution_ lynx.cfg be initiated for the Novice.

> 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

Oh, glad to hear that, especially the "NS" part.

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

I certainly don't think so.

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

Is it worth having reload for this?

> I really don't know why you repeatedly bring up MSIE.  It doesn't

Well, it really is kind of nasty on my part.  At this very moment I see
an 'e' with a ring around it in the lower left of my display.  Will my
right hand reach over and click on it, or will I do a ^a (screen jive)
and launch Lynx?  Decisions about how Lynx should be are tipping the
scales right now.  Let's just hope my fingers stay on the keyboard
because if a diehard like me goes by way of the mouse, you'll have
another dying breed on your hands. :)

> completely misunderstood you.  If so, *please* clarify.

Well, I've probably been away from English longer than you've been in it.
Did I make things any clearer?  I tried my best.

__Henry