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