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

[Vlad Harchev]

On Sat, 18 Dec 1999, Henry Nelson wrote:

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

 I'm happy :-)
 Fine that you admit it. Then please don't ask for providing configure
settings that will disable certain features for sake of saving several
kilobytes of binary (almost all of your requests were about removing some
feature - I don't remember any of your messages like "I like this
functionality to be added" - all are "do we need this?!!!"), at least so
intensively, or ask other developers not to follow your wishes very close if 
they don't want to, and please don't ask about stopping the growth of the 
number of lynx.cfg options - please don't ask for making lynx unflexible.
  You are not the only lynx's user.

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

 Really? With your collection of patches to lynx?
  
> > 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 also think that .lynxrc is a relict. Of course dropping functionality it
provides (ie ability to configure some parametes that user is allowed to
alter) is a bad idea. I was thinking about machanism providing ability to
edit and apply (at runtime) (and probably save, but this is too difficult
to preserve all comments) most of the settings in lynx.cfg (or part of it,
specified by site admin) via something like options screen, providing ability 
to site admin to control a list of options that could be controlled by user 
via such screen and what options could be read from user's specific lynx.cfg 
(this is already implemented, via extened syntax INCLUDE directive). But I was
also thinking about providing ability to specify different values for options 
in lynx.cfg depending on the URL of the document - seems solution that will 
satisfy both wishes will be technically not very elegant. 
  
  I was also thinking about slightly changing behaviour of -cfg
commandline option - IMO if it's given several times, it should read all files
specified by it's arguments, not only 1st. But this is very easy to fix.

>[...] 

 Best regards,
  -Vlad