Red Hat Bugzilla – Bug 250016
Emacs site-start.el vs default.el
Last modified: 2008-06-16 22:00:14 EDT
Description of problem:
Citing the documentation for Emacs's `site-start' variable:
Don't use the `site-start.el' file for things some users may not like.
Put them in `default.el' instead, so that users can more easily
override them. Users can prevent loading `default.el' with the `-q'
option or by setting `inhibit-default-init' in their own init files,
but inhibiting `site-start.el' requires `--no-site-file', which
is less convenient.
This would be good advice to follow, yet Fedora (and RedHat, I assume)
dumped it completely and moved *all* packages to site-start.el, leaving an
Personally, there are emacs packages that I want to use, but I want to set
them up myself. On multi-user machines, it is also a problem if users have
no control of all that stuff being done for them.
Actually, Eli I think it is done correctly. If you read the emacs manual, the
order the files are loaded in is this:
2) User .emacs
So, the user's .emacs CAN override things set in site-start.el, but NOT
default.el. However, the piece of text you quote above does seem to contradict
this. Read here:
I can override settings that were made by packages, but I cannot avoid loading
them! Try to disable site-start.el and see just how much faster Emacs starts.
(This was noticeable enough even on a new quad-cpu ultra fast server, which is
why I complained in the first place.)
But more than that, many packages change things -- so if I don't want to see a
certain package, I need to look at the source, then write code that will undo
all global changes. With a large number of packages, this is getting to be a
mini-project. And to make things even more fun, I wouldn't be surprised if
there are some changes that cannot be undone.
So using site-start.el should be restricted to only files that make no global
changes, and that load very fast. This is what packages that come with Emacs
do -- these packages do not much more than installing an autoloaded function or
custom variable etc. Random packages that RH distributes are usually at much
lower standards, so enforcing such policy on packages doesn't seem to be
Moving the loading of these files to default.el means that it is easy to disable
loading them. Interacting with such packages is still possible -- this is why
`defvar' does not change the value of an already set variable. It's even
possible to write code that depends on a library, using `eval-after-load'.
IMO: if an external elisp package changes some default emacs behavior,
that is a bug. I think allowable modifications (this is off the top of
my head) at startup are: autoloads, defvar (or defcustom), and adding
entries to auto-mode-alist (and perhaps one or two other similar things,
The problem with loading things from default.el and not site-start.el
is that, with the default.el approach, you cannot refer to the add-ons
from your .emacs.
Re external package changes: that's what I said. The thing is that there are
*many* packages do not follow that, so you'll need to start with a whole bunch
of bug reports. But it's more than just forbidding other side-effects: each
package should be split to the minimum file that provides auto-loaded functions
and custom variables, and the rest. Without that you still get penalized for
loading a bunch of stuff. And given that this was very noticeable on a pretty
strong machine, my guess is that people on weak machines just assume that Emacs
is always very slow to start.
And re the problem with loading things from default.el -- see the last paragraph
of my previous comment -- it is still possible using `defvar' and
`eval-after-load'. This is quite common when dealing with packages that are
bundled with Emacs (since Emacs doesn't load them by default, unlike the current
Aren't there likely to be a lot of users out there who are referring to package
variables and functions in their .emacs files who will file new bugs if the
package initializations are moved to default.el?
I'm sure there will be, but the bug is still the same...
Perhaps a solution is to change the way emacs packages are made -- use the
same thing that Emacs uses -- extract ";;;###autoload" stuff and construct
a fast-loading (and side-effect-free) .el file?
Maybe we can narrow the requirements a little further. What are the specific
side effects that are making trouble for you?
* Above all it's the speed. If it's bad enough on my machine to finally
convince me to turn it off, then it's horribly slow on laptops etc.
(BTW, none of the site-start.d files are compiled, which makes it more
* This is probably mostly due to loading files that have the actual content
rather than just autoload stubs. (eg, muse)
* Some packages don't have an immediate side-effect, but deferred to hooks.
For example, it's enough to visit a logo file to change my colors
completely, and later visiting a php files changed colors again.
* There are some packages that I want to override with my own copy (eg,
packages that my own very keep up-to-date copy) that can only be loaded
twice since I cannot avoid loading site-start.el.
* Also, there were packages that associated modes with files that I didn't
* colors become completely different than I want to. And since I like black
background I get some unreadable stuff on my screen.
* Some other changes to minibuffer input (again, no clue who does that, but
my own minibuffer hacks are ignored).
* the worst offender that I remember was the flim package and some of its
relatives which destroyed dealing with email (and mime) to the point of
completely breaking my mailer (vm).
* Also, there is a "vm-mode-init.el" that intentionally changes vm.
* There are some other packages in this category, like muse, which is very
invasive (and makes an extra effort to destroy colors, email, latex, info,
html, and more).
Most of those sound like bugs to me.
In re comment #4 -- I think it is fine to have a bunch of bug reports
against packages violating emacs packaging rules.
A few comments on the list:
* Looks like that php mode is semi-bad. It sets font-lock-maximum-decoration
without making it buffer-local, among other things.
* If you want to override a package, it should be no problem to set load-path
in your .emacs. Changing to default.el would seem to make this harder.
If there's a packge you can't override, again, I think that is most
likely a bug in that package -- since packages should limit
what they eval at startup, and autoloads are generally safe here.
* If u-vm-color.el is not part of the upstream VM, then IMO we shouldn't
ship it. I assume this is what you mean about changing VM.
* Fine with me to split this to multiple bugs... (I won't hold my breath
though, it'll probably take a good chunk of time to flatten them all out.)
I'll even test things from release to release...
* If you do split it, please start with some strong hammering over the flim,
muse, and mew packages. (The last one broke stuff so much last time I
tried, that I avoid it like the plague now.)
* Also, if you go down this road, there should probably be some very visible
warning along the way for getting an rpm for emacs -- something that will
clarify what site-start.d files should and should not do. (Without that I
think that it will be inevitable to get yet more mess.)
* I'm not sure that it was the decoration level that caused the problem that
I have seen, but my Emacs was off its usual anyway so I can't say much more.
(My modeline changed colors, but that could have been someone else in the
* Changing the load-path in my .emacs does not avoid loading a file from
site-start.el. This would not be a problem if it's restricted to
well-behaved autoloads only...
* I don't know if u-vm-color is part of vm or not (seems that vm changed hands
not too long ago), but unconditional changes are not a good idea.
This message is a reminder that Fedora 7 is nearing the end of life. Approximately 30 (thirty) days from now Fedora will stop maintaining and issuing updates for Fedora 7. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as WONTFIX if it remains open with a Fedora 'version' of '7'.
Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version prior to Fedora 7's end of life.
Bug Reporter: Thank you for reporting this issue and we are sorry that we may not be able to fix it before Fedora 7 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora please change the 'version' of this bug. If you are unable to change the version, please add a comment here and someone will do it for you.
Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete. If possible, it is recommended that you try the newest available Fedora distribution to see if your bug still exists.
Please read the Release Notes for the newest Fedora distribution to make sure it will meet your needs:
The process we are following is described here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Fedora 7 changed to end-of-life (EOL) status on June 13, 2008.
Fedora 7 is no longer maintained, which means that it will not
receive any further security or bug fix updates. As a result we
are closing this bug.
If you can reproduce this bug against a currently maintained version
of Fedora please feel free to reopen this bug against that version.
Thank you for reporting this bug and we are sorry it could not be fixed.