Re: A vote for BOTH userdefs.h and lynx.cfg [was Re: LYNX-DEV help: finally!]

[Nelson Henry Eric]

> > I put in a strong vote to NOT do away with the POSSIBILITY
> > of making all defines in  userdefs.h .
[...]
> as a representative of those installing Lynx for a user community,
> BUT there's also quite a few others -- eg me -- who install Lynx
> for their own (personal) use & hence have a different point of view.

Definitely agreed, understood and sympathized with.  (I, too, compile
Lynx for personal use only on two PCs, one FreeBSD, and very recently,
Linux.)  I was only talking about the _availability_ of the userdefs.h
mechanism, not whether it is presently supported well or not.

> but due to history has tended to take the sysadmin's viewpoint as basic.

I've put in my part to correct the situation (INSTALLATION only talks about
the anonymous account stuff now once with one additional warning, whereas
before it repeated verbatum 100+ lines on the subject.  It also explicitly
says you may skip those steps.  I think you helped me crusade for rearrangement
of userdefs.h to put that anonymous stuff at the end and label it.)

> which is my very own version for me alone.  to accommodate both viewpoints
> it seems simplest to have only security items in  userdefs.h
> -- they're only for sysadmins -- , putting some basic choices in switches
> for  configure  -- eg the path to  lynx.cfg  : these should NOT default
> to the sysadmins' version  /usr/lib  or whatever -- & leaving the rest

Do not forget that as soon as you compile Lynx for your personal use, YOU
become the defacto sysadmin.  You can turn this to your advantage.  Also, as
was pointed out, if you are on Unix and use configure, you don't need to do
ANY editing of the file.

Thus, I still am not convinced that the best way to "accommodate both
viewpoints" is to decentralize, i.e. break up, userdefs.h.  I do agree that
_reorganization_ of the Unix section is in order.  It might also be useful to
reorganize userdefs.h completely in the manner of the compile sections for
INSTALLATION, maybe even keep the same order as in INSTALLATION, namely Unix,
VMS, Win32, DOS386.  -- but not me, at least until August or September.
Thanks for volunteering! :)

> to be decided in  lynx.cfg .  Henry's  100  users can be best served
> by having a central version of  lynx.cfg  (determined by Henry),
> with some advice to them that they can override it thro'  -cfg  at run-time.

No.  This means that the 400+ (I let graduates keep and use their login
accounts as a reward for plugging through unix.) account holders would have
to rewrite their lynx.cfg's, in addition to maintaining a much larger one
than they presently have (or don't have depending on their preference).
With the userdefs.h mechanism I can do backwards capability for everyone
with one patch, whereas editing everybody's lynx.cfg is a MAJOR administrative
nightmare (for me anyway).  I tell you, there are a lot of free nets out
there struggling by on a lot less than me; I'd like them to do configuration
whatever way is easiest for them.

The problem is, you cannot tell the same Lynx image to read TWO lynx.cfg
files, a default and a personal preference one.  Defaults are conveniently
compiled in (and there is no reason why you can't do that, too), and
preferences are easily configured at run-time to override any default you
would want without HAVING to define any default that works for you.

> clearly, the introduction of  configure  & (dare i say it?) the absence

The majority of compilers, but we must not forget that NOT ALL, are indeed
unix people.  Still, if you are really arguing for configure, then why do
you bother editing userdefs.h at all?

> gives us an opportunity to clean up the way in which Lynx is presented
> & the way in which the documentation is organised.

again, again.  THANKS for volunteering. :) :)

__Henry