minor points regarding initialization files
Lynn David Newton writes:
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.
site-lisp is deprecated. Anything in site-lisp is entirely your
problem, except that if you configure --with-site-lisp, XEmacs will
put that directory in your load-path automatically.
The rationale is that if you put stuff in packages, then XEmacs can
help construct a run-time layout and auxiliary files (auto-autoloads,
custom-load) that automate initialization. For purely personal code,
this is a matter of your experience with packaging and personal
preference. But for code that is shared and maintained, it doesn't
take much sharing or maintaining to make packaging a useful skill.
Anything in site-lisp, however, requires manual autoloads and/or
explicit requires, and you won't be able to use customize without a
previous load/require.
site-lisp is also a frequent source of hidden variation in bug
reporting, which is why it's off by default.
I tried to rename this directory site-lisp, but found that xemacs
can't
find it
I don't recall if site-lisp was ever recognized under ~/.xemacs --
.xemacs itself was where most people kept loose libraries of a
personal nature.
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,
Yes. With the caveat that this happens very early, so neither
packages nor .xemacs are in the load-path at that point IIRC.
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.
Yes.
Is site-start.el(c) automatically loaded -- first -- if I don't
explicitly load it?
It is, but you have to put it in the right place. To suppress
site-start as well as init and default, use -vanilla instead of -q
(this also suppresses auto-autoloads from packages but not addition of
package lisp to load-path IIRC).
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.
It could be put in a package somewhere. I don't much like it for core
or enabled by default, too much chance for things to go wrong if you
try to recover from errors automatically.
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.
Yes, it's a horrible default, anywhere. CWD-in-PATH is a wonderful
convenience for humans working interactively and viruses working
automatically. You can do that if you want, and if you have some idea
what you're doing security-wise it probably won't hurt. But it will
never be a distribution default. In fact, there was a CERT recently
about a package that automatically loaded code from CWD even if it
wasn't in load-path.
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://lists.xemacs.org/mailman/listinfo/xemacs-beta