Path: utzoo!utgpu!watmath!iuvax!cica!tut.cis.ohio-state.edu!BBN.COM!jr
From: jr@BBN.COM (John Robinson)
Newsgroups: gnu.emacs
Subject: Re: Stupid question
Message-ID: <7004.622476366@bbn.com>
Date: 22 Sep 89 14:06:06 GMT
References: <8909211925.AA07891@life.ai.mit.edu>
Distribution: gnu
Organization: BBN Systems and Technologies Corporation, Cambridge MA
Lines: 85

First, it is not a stupid question!  There are a lot of things you can
do in configuring an emacs, and there is no guidance that I know of
other than the net and what little you have found in the manual in how
to do this (well, if the emacs-lisp maual says something, I might be
too pessismistic here).  I am posting this answer because I want to
increase the information flow on this topic.

It would be nice to collect some of this folklore together into an
emacs administrator's guide.  Anyone want to step up to this?

> 1) How do I take advantage of these packages?  How do I "install"
> them, and where do I install them?  (Ie, do I save the packages in
> appropriately labeled files in the emacs/lisp directory?)

That would work.  You would probably also want to byte-copmile them
once they are there.

Here's what I do (config: 18.55 and Sun3, but OS 3.5).  If I think a
package looks useful (which means, I would expect to use it :-), I put
it in a directory I created under $EMACS/lisp called lisp/local/ .
Then I (amd anyone else can) add this to my load-path variable.  This
keeps these things out of other people's way, which is important if
they are replacements for standard packages using the same name.  If
someone else wanted a package to be available, I would put it here
too.

For big packges I create a separate directory; two examples I have
here are lisp/gnews and lisp/vm.  This is because these packages each
have a number of files which get updated as a group.  What I actually
have is lisp/vm-4.40/, and lisp/vm is a symbolic link to vm-4.40.  In
this way, I can "install" a new package version merely by changing the
symbolic link.  I use a similar trick for emacs versions as well
(e.g., /usr/local/emacs/lisp is a link to dist/lisp, and dist is a
link to (today) dist-18.55; so the eventual resolution of Init.el with
a load-path including /usr/local/emacs/lisp/vm will be:

  /usr/local/emacs/dist-18.55/lisp/vm-4.40/vm.el

 ).  The only thing I don't like as much about this is the need to
copy the extra package directories to the new directory structure when
I pick up a new distribution.  This would be solved by putting the
packages above the dist-xx.xx level and linking up to there from the
lisp/ directory; someday...

> 2) If I'm recompiling gnuemacs, should these packages be loaded into
> the dumped emacs?  If so, should I put the packages in site-init.el or
> keep them in separate files (and edit the xmakefile so that it loads
> these files)?

No one else takes much interest in it here, so I set up the loaded
packages to suit my usage pattern.  Here's my site-init.el:

  (load "time")
  (load "mh-e")
  (load "ebuff-menu")
  (load "sun-mouse")
  (load "sun-fns")

The only big package is mh-e, which I and a lot of others use all the
time.  The sun-related ones are because many use suns and sunview
around here.  ebuff-menu (electric buffer menu) is a personal
favorite, and small.  time is small, and most everyone uses it as
well.  Note that I don't set any variables here.  My attitude is that
I don't want to deviate from the "default" settings that come with
emacs, unless there is a compelling reason, so as to avoid confusion
(especially for novices) when things don't match what the manual says.

I have often thought of installing a variant of load-library (or a
load-hook) that keeps a history of what I have loaded so I can
re-optimize the site-init file later, but I haven't bothered.  I have
also speculated about building an emacs which included everything I
could possible imagine wanting loaded, and seeing how big it became
(and how performance was).  Maybe when I get a Sun with a shoebox...
I wonder it it would blow the 24-bit pointers ;-).

I don't change the xmakefile (ymakefile) from the standard other than
to set -O in the compile flags and get the pure length right for the X
support to be included in addition to sunview.  This means the doc
strings for the packages loaded by site-init are not put into the DOC
file, but tht doesn't seem to cause any particular troubles.
xmakefiule could perhaps be a little more clever here about how it
decides what to scan for docstrings.
--
/jr, nee John Robinson     Life did not take over the globe by combat,
jr@bbn.com or bbn!jr          but by networking -- Lynn Margulis