Question batch 2 has to do with start-ups. The installed directory /usr/local/share/xemacs/site-lisp is empty, which I gather is reserved for stuff that may be locally needed: original and customized packages, etc. I guess that was be a question. Be patient with me while I relearn all this stuff. Typically Macs are used by only one user, so having stuff out in /usr-land so others can see it is not usually necessary. Come to think of it, I could probably use a configure option to install somewhere beneath my home directory. I think I used to do that, but haven't for a long time. My way of dealing with site-lisp that has long been to put all that stuff either in ~/.xemacs or ~/.xemacs/site-packages, which I discovered by experimentation automatically becomes included in load-path. I tried to rename this directory site-lisp, but found that xemacs can't find it -- unless I add it to load-path. Really?? Why would that be true? Not that it matters. I renamed it back to site-packages and it works fine again. Another advantage of having it in ~/.xemacs is that the stuff doesn't disappear. When my previous main system, a MacBook Pro, bit the dust, it did so bigtime. I had careful backups of everything in my home directory, and lost not a thing, but kept nothing outside of there, so it's been a job creating a new working environment -- a task that's been not unenjoyable because it's good to clean house once in a while. But if all my customized elisp stuff existed only outside my home directory, I would have lost it all. So question 2b has to do with site-start.el. I seem to remember that at least in ancient times xemacs would look (first?) for a file site-start.el(c) in its load-path, and would run that stuff first. There is no such file in the default installation, so I guess it's up to users who want one to create one. I do, because I use it to put some defuns that are extremely useful during initialization, and also to declare some global properties up front, also key bindings for eval-region and eval-print-last-sexp, useful in debugging startups. Is site-start.el(c) automatically loaded -- first -- if I don't explicitly load it? I gather it is *not* -- otherwise xemacs -q would be prone to frequent failures. My brute force way of dealing with that has in the past been to put the following as the first form in my init.el: (load-library "site-start") I also use a load a module I picked up from somewhere called safe-load (author said to be Lawrence Juja, dated way back in 1992), which prevents initialization from blowing up after every error. It just creates a list of the failing packages to look up after it comes up. This has saved me endless headaches, and I wish it were in the default distribution. At the end of my init.el I also prepend nil to load-path to make the current directory a place to look, a trick I picked up long ago. Is there anyone here who thinks that having the CWD searched first is philosophically a bad idea? I know people who think that about $PATH, though I've always (for maybe 25 years) had my $PATH variable prefixed with a colon for the current directory. BTW, I don't use only init.el for startups. I use that mainly as a control file to load another of other files that give me home brewed defuns, key bindings, mode-specific stuff like hooks and one that I needed because certain stuff could only be done *after* loading hyperbole (that's another question for a later post), also a handful of saved keyboard macros I never turned into defuns, and so on. A total of over 3100 lines in those files (according to wc), most of it still stuff I use. Still more to follow. -- Lynn David Newton Columbus, Ohio neologisticsediting.com lynndavidnewton.com _______________________________________________ XEmacs-Beta mailing list XEmacs-Beta(a)xemacs.org http://lists.xemacs.org/mailman/listinfo/xemacs-beta