Re: lynx-dev suggested addition to lynx.cfg

[Klaus Weide]

On Tue, 13 Jul 1999, Vlad Harchev wrote:
> On Mon, 12 Jul 1999, Klaus Weide wrote:
> 
> > I suggest the following be added at the end of lynx.cfg:
> > [ ... ]
> > #INCLUDE:~/.lynx.cfg

...and there is some conversation prompting me to that suggesting
archived under <http://www.debian.org/Bugs/db/pa/llynx.html>,
Vlad please read #16214.

> > The point of recommending a specific name is to prevent different
> > linux distributions (or similar packagers) from inventing different,
> > incompatible conventions; I don't really care what the suggested
> > name is.
>
>  Can you give any examples of incompatible conventions used by different linux
> distributions (what is meant by 'convention')? With what are they 
> incompatible?

With each other...

I don't want to get into the general topic of "incompatible conventions
between linux distributions", that doesn't belong here and I don't really
know that much about it.

The "incompatible conventions" w.r.t. lynx is, for now, completely
hypothetical.  But if it becomes popular for packages to provide a
"hook" to a user-specific file, it should better be the same.  It
would not be good if RH had
  #INCLUDE:~/lynx-cfg
and Debian had
  #INCLUDE:~/.lynx.cfg
and somebody else's .tgz had
  #INCLUDE:~/.lynx-override .

> Is this a technical or philosophical problem? Does it hurts anybody? (I used
> only RH and nothing else, so I have no experience with other distributions).

It could create confusion for users that switch from one distribution to
another, or just from installing e.g. a RH package to installing a
(converted) Debian package: things that used to work now don't work any
more.  Having the same file name also makes it easier for a user of one
packager's package to talk to the user of another packager's package
(or to lynx-dev).

> It seems to me that packagers tweak only STARTFILE setting to point to some
> local html file, and everything else is unchanged.

The Debian package (2.8.2-1) makes changes to lynx.cfg for:
  STARTFILE
  HELPFILE
  LOCAL_EXECUTION_LINKS_ALWAYS_ON
  LOCAL_EXECUTION_LINKS_ON_BUT_NOT_REMOTE
  TRUSTED_EXEC
  ALWAYS_TRUSTED_EXEC
  TRUSTED_LYNXCGI
  USE_MOUSE
  DEFAULT_EDITOR
  NO_DOT_FILES
  GLOBAL_EXTENSION_MAP
  XLOADIMAGE_COMMAND
  GLOBAL_MAILCAP
  COLOR
  NNTPSERVER
in addition to removing (mostly) VMS-specific text.  (For the exec/cgi
stuff it's just making the "safer" defaults explicit by uncommenting
them.)  You can find the diff here:
<http://ftp.debian.org/debian/dists/unstable/main/source/web/lynx_2.8.2-1.diff.gz>.

>  IMO this proposal breaks several traditions (eg 2 different configuration
> files for in one directory for one software package, but agree that 2nd file 
> is allowed not to exist).

One file (.lynxrc) is a file created and maintained by lynx, at least
that's what it's meant to be.  The other (.lynx.cfg in my proposal)
is maintained by the user if he/she wishes so.  They are not configuation
files in the same sense.

I don't know what you mean by "2nd file is allowed not to exist".
None of the 2 files have to exist.

Maybe this breaks some tradition, and I think you want to use a
subdirectory for lynx's files.  Well, at least for .lynxrc this would
"break the Lynx tradition" that .lynxrc in $HOME is used.  Until you
have it all sorted out and updated all the relevant documentation,
do you have something that can be suggested now?

>  A question: if at startup lynx finds lynx.cfg in the HOME
> directory, does it opens this file (and not opens site-wide file)?

No.  Unless specifically told so, as in:

>  Also lynx uses $LYNX_CFG environment variable for the location of lynx.cfg
> file. 

>  - I asked that question because it seems to me that:
> * lynx power users ignore disrtibution's lynx.cfg completely and use their
>   own lynx.cfg file (by setting $LYNX_CFG to somewhere in their home). (so
>   proposed change won't affect them)
> * other users don't even know that lynx has configuration file anywhere (or
>   even that lynx exist) - so the proposed change won't make any effect on
>   them.

It seems to me that there is a significant number of intermediate
level users that you ignore.  And also many users who don't want
to (have to) completely copy the system's lynx.cfg, but would want
to change some aspect (like COLOR) while relying on the system's
lynx.cfg for most settings.

It's also inconvenient to have to set LYNX_CFG.  (Try to describe in one
sentence to a new user which files to modify, taking all possible
login shells into account.)

> IMO we should start README.packager (IMO better to have it at the top of
> tree) file and describe there what are recommended switches to configure, what
> are recommended default lynx.cfg settings - in 'for impatient' manner - this
> will help packagers a lot.

Good idea, please do so.  Although one would hope that packagers notice
differences in lynx.cfg ...

Btw. various of the Debian bug reports also show that people are
confused between lynx.cfg and .lynxrc.  That confusion seems to be
among people who think "lynx must have a user specific config file,
I have seens .lynxrc somewhere so I'll just create that file and
put lynx.cfg settings in it".  I thinks this shows there is a market
for 'user specific configuration files that can do what lynx.cfg
can do without having to set environment variables'.  But we don't
have to change anything in lynx itself, just point people in the
direction of using your INCLUDE - you should be happy :).

(I don't see the Grand Unification of Lynx Option Mechanisms
That Makes Everything Simpler (And Works Right!), that might
change all this, coming soon.  Just my opinion, which might be
proven wrong.)


   Klaus