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