Path: utzoo!utgpu!watmath!uunet!bu-cs!encore!multimax
From: pierson@multimax (Dan Pierson)
Newsgroups: gnu.emacs
Subject: Re: Stupid question
Message-ID: <9998@multimax.Encore.COM>
Date: 22 Sep 89 18:25:29 GMT
References: <8909211925.AA07891@life.ai.mit.edu> <7004.622476366@bbn.com>
Sender: news@Encore.COM
Reply-To: pierson@multimax (Dan Pierson)
Distribution: gnu
Organization: Encore Computer Corp
Lines: 37
In-reply-to: jr@BBN.COM (John Robinson)

In article <7004.622476366@bbn.com>, jr@BBN (John Robinson) writes:
 >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.

I use $EMACS/local instead so that the entire $EMACS/lisp directory
can be replaced in a new install.  Maybe we could all agree on a
convention here?  New, (genuinely) improved versions of standard
packages go in $EMACS/local; bug fixes that are critical or virtually
certain to be included in the next version of GNU Emacs go in
$EMACS/lisp.  Changes to keybindings and major user interfaces are not
included in anything that gets loaded without explicit user choice.

 >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 do the same thing, in fact my biggest complaint about VM is that I
have to modify every new version so that it loads its support files
from "vm/vm-foo" instead of "vm-foo".  Having all of a large package
in one subdirectory makes it much easier to maintain the package.  It
especially simplifies installing a new version parallel to the old one
for beta-testing.
-- 
                                            dan

In real life: Dan Pierson, Encore Computer Corporation, Research
UUCP: {talcott,decvax,bu-cs}!encore!pierson
Internet: pierson@encore.com