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 empty default.el. 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: 1) site-start.el 2) User .emacs 3) default.el 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: http://www.gnu.org/software/emacs/manual/html_node/emacs/Init-File.html#Init-File
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 feasible. 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, e.g. interpreter-mode-alist). 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 Fedora/RH setup...).
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 verbose.) * 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 expect, * 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 middle.) * 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: http://docs.fedoraproject.org/release-notes/ 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.