[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: lynx.cfg AND/OR .lynxrc [was: Re: lynx-dev lynx2.8.3dev.17
Re: lynx.cfg AND/OR .lynxrc [was: Re: lynx-dev lynx2.8.3dev.17
Tue, 21 Dec 1999 12:20:28 -0600 (CST)
On Mon, 20 Dec 1999, Henry Nelson wrote:
> 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.
I have to admit that I was *thinking* of making some similar addition,
at some point in the future (to the Cookie Jar screen). Something like
"Temporarily suspend all cookie sending/receiving" (but I wouldn't
"reuse" the O.M. code for this). I guess you wouldn't like it...
> 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.
Well, nobody complained immediately... but that omission has changed now. :)
> 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.
Well - strictly speaking, nothing gets directly "posted to" .lynxrc.
A set of desired option values (determined by the current state of
form fields) gets posted to some handler code (function
postoptions()). The handler code may or may not accept the submission.
If it does, the handler code changes the currently active set of
run-time options to what is desired, and then that same handler *may*
also save _part of_ the new current state of options to .lynxrc.
(This describes the form-based O.M., key-based is different.)
Now, postoptions() was only ever meant to be used from the Options Menu
itself, according to all available evidence (comments and code).
However, the V.Links patch author found that this isn't actually
enforced, so apparently, he figured, no problem duplicating part of
(what he also added to) the Options Menu on the V.Links page
itself. Nevermind that the postoptions() handler isn't even compiled in
if the form-based O.M. isn't compiled in...
 This is what the quoted CHANGES entry is about. Note that this check
is completely unspecific as to saving-to-.lynxrc or not.
 Whether the handler does save to .lynxrc depends on (a) whether
it's allowed (option_save restriction) and (b) whether it's requested
as part of the form submission. Now, in this case the request, as it
is generated by the V.Links mini-form, doesn't *ask* for saving, so no
saving will happen for this reason. Only the currently active state of
the B.Links style option gets changed to the requested setting.
 The "part of" currently active settings that can get saved to
.lynxrc is always the same - all options that are saveable (which don't
have a (!) on the Options Menu - *assuming* that that indication is
correct). In order to actually have the V.Links style setting saved to
.lynxrc (and read from it on startup), specific code would have to be
added to LYrcFile.c for doing the saving and restoring. The patch
author didn't do so (I think we agree it should be saveable). He
didn't do what's necessary for the (!) to appear, either.
> I guess off-topic, but why is Visited Links allowed to submit option changes?
I didn't want to "break" it. But no, I didn't want to "fix" it either,
so that we can all enjoy this discussion... (I hadn't really looked
closely at the new V.Links at all; just noticed that it depended on
postoptions(), more or less by accident.)
> Why can't, or why shouldn't we limit that to the forms-based Options Page
We can; let the discussion continue if anyone's still listening...
> > 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.
With that, I meant also that, given approximately the current approach,
you wouldn't be able to "turn it off" at all if it can be only changed
in the O.M. (since it's only in the *form-based* O.M. code and you
don't compile that in). (Well if it was saveable/resoreable you could
edit .lynxrc by hand.)
(Of course if defaults were as they ought to be according to your and
my preference, we'd rather talk about places to "turn it on".)
> Is there something wrong with this? Why in the world do we want more than
> one place to turn it off?
With the "two places", I meant as a lynx.cfg option and a User
Preferences option, without being specific as to where the User
Interface to the latter would be (O.M., or V.Links, or both).
That was probably unclear.
> 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.
Do you see the sense, with my more specific meaning of "multiple"?
> 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.
An entry in lynx.cfg should be there. Without it, users of a lynx
compiled with only the key-based O.M. could never change the setting.
Besides, having all O.M. settings "backed by" lynx.cfg-changeable
defaults is the traditional thing, the lynx-standard thing, new options
shouldn't deviate from it on a whim and without good reasons. Existing
deviations notwithstanding. It's those deviations that created
inconsistency and confusion, not the fact that some (most) O.M. settings
are "duplicated" in lynx.cfg.
As for a configure --disable flag - I'm ambivalent.
> > 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_.
Not to forget 2.2, as we've just seen...
[ BIG SNIP - maybe still more later...]
> > 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. :)
It's you who has to live with the consequences. :)
> Did I make things any clearer? I tried my best.
Yes (although I still don't see how it would fit in that you seemed
to prefer option-in-O.M.-only to option-in-lynx.cfg-and-O.M...).
I hope I didn't confuse things further.
- lynx.cfg AND/OR .lynxrc [was: Re: lynx-dev lynx2.8.3dev.17, Henry Nelson, 1999/12/17
- Re: lynx.cfg AND/OR .lynxrc [was: Re: lynx-dev lynx2.8.3dev.17, Henry Nelson, 1999/12/18
- Re: lynx.cfg AND/OR .lynxrc [was: Re: lynx-dev lynx2.8.3dev.17, T.E.Dickey, 1999/12/18
- Re: lynx.cfg AND/OR .lynxrc [was: Re: lynx-dev lynx2.8.3dev.17, Henry Nelson, 1999/12/20
- Re: lynx.cfg AND/OR .lynxrc [was: Re: lynx-dev lynx2.8.3dev.17, Henry Nelson, 1999/12/21
- Re: lynx.cfg AND/OR .lynxrc [was: Re: lynx-dev lynx2.8.3dev.17, Henry Nelson, 1999/12/22