thakur%cfa201@harvard.harvard.edu (Manavendra K. Thakur) (09/22/89)
I'm going to ask what is most likely a very stupid question. So if
this sort of thing annoys you, delete this message *now*.
I keep seeing these wonderful lisp packages being sent out onto the
info-gnu-emacs mailing list. My questions are:
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?)
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)?
Note that I'm asking for tips and guidelines on the best way to
load/use these pacakges. For example, I know that you can put in
anything you like in site-init.el. I'm trying to get a sense of
whether people reserve site-init.el for simple variable overrides (as
described in the emacs installation notes) or if people also put in
large packages etc. in their site-init.el. As you can see, I'm
more interested in what is practical and useful rather than just
possible.
Any help would be greatly appreciated.
If it matters, I'm trying to compile GnuEmacs 18.55 on a Sun 3 running
SunOS 4.0.3.
Manavendra K. Thakur
System Manager, High Energy Division
Harvard-Smithsonian Center for Astrophyics
thakur@cfa.harvard.edu
thakur%cfa201@harvard.harvard.edujr@BBN.COM (John Robinson) (09/22/89)
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
liberte@CS.UIUC.EDU (Daniel LaLiberte) (09/22/89)
I think it is better to leave most of GNU Emacs in the default configuration as it is documented. Any changes you make should be well known (i.e. documentation may not be enough) to those who will be affected, or transparent. We have one package that is loaded up by site-init.el (to save load time), but to keep all of its definitions out of most users' name space, they are all defined inside of one function, which is then called by users who want to use the package to define everything else. Be aware, however, that previous versions of the byte-compiler failed on defuns inside of defuns. Dan LaLiberte uiucdcs!liberte liberte@cs.uiuc.edu liberte%a.cs.uiuc.edu@uiucvmd.bitnet
pierson@multimax (Dan Pierson) (09/23/89)
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