Re: run/load a lisp script before user init file

[Stephen J. Turnbull]

Harald Hanche-Olsen writes:

 > If one were to think along these lines, wouldn't it make more sense to
 > have a directory "site-start.d" where packages can put their own
 > initialization code, each in its own file? It makes uninstalling
 > trivial, for one thing.

site-start is a Lisp file; you can already have that if you want.

Also, in XEmacs and SXEmacs you can just put the needed code in an
autoload cookie in the package itself, and it automatically gets
executed when loading the auto-autoloads.  I don't know if there is a
similar feature for ELPA packages, but I imagine there is.  (In
XEmacs, this code actually gets executed before site-start IIRC.)

Jarek Czekalski writes:

 > W dniu 2013-10-08 08:27, Stephen J. Turnbull pisze:
 >> It doesn't actually solve any problems, and makes some of them harder
 >> to solve (eg, uninstall).

 > I thought it makes uninstall easier. Just erase the file you
 > added. I mean that during install I add the file
 > site-lisp/emacspeak/site-start.el.

A complete uninstall, yes, but how about disable (you can't remove the
site-start file if it contains much code) or uninstall-but-leave-conf
(you don't want to leave the site-start file behind because it will
cause startup errors)?  You could probably make it work, but really,
there are better approaches.

 >> It's ugly (why should the site-start library be treated differently
 >> from any other?[1])

 > I don't think of site-start as of a library.

It's not your choice, and it's not really Emacs's, either.  site-start
is an ancient interface, and sufficiently well-established that
changing it would very likely surprise people.  It would also be a
PITA: you can't use locate-library to find the file you want.  The
site-start.d approach is much better, as is the auto-autoloads
approach.  (Note that although the name "auto-autoloads" is shared by
all packages and core in XEmacs, it's always a generated file, so you
don't want to edit it anyway.  The right appropriate is to put the
initialization code in a function, and then call that.  To find that
code you use find-function.)

 >> It's not general (I suspect that at the point where site-start is
 >> run, the load-path is very short.)

 > No. On Debian it already contains dozens of paths.

Debian already has site-start.d, so who cares about Debian?  You're
proposing a change to the upstream Emacs, which is a different matter.
And on the upstream Emacs, I would guess there are only 5-10 paths,
and they wouldn't be appropriate locations for a 3rd-party start file.

 >> What's wrong with the obvious solution?  Like this:
 >>
 >> 1. Install your script on the load-path in some application-specific file.
 >> 2. Compile it.
 >> 3. Find site-start.  If it doesn't exist yet, create an empty one.

 > Easy to say: "Find site-start". How? Let's have a difficult
 > example:  Debian.

Again, forget Debian.  Debian has its own Emacs Policy, and you'd want
to conform to that rather than try to override it from upstream.

In any case, it's easy to find the right site-start:

  emacs -batch -q -no-site-file -eval '(prin1 (locate-library "site-start"))'

should do the trick if it exists.