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