Romain Francoise <[EMAIL PROTECTED]> wrote: > Peter Galbraith <[EMAIL PROTECTED]> writes: > > > 1- Perhaps if I don't explicitely add > > /usr/share/emacs/site-lisp/emacs-goodies-el/ to the load-path, it > > will get added automatically at the tail end, because it is a > > subdirectory of /usr/share/emacs/site-lisp ? > > Nope, it won't be added automatically.
Okay, thanks. > > 2- Perhaps emacs-snapshot can be modified to have it's generic load-path > > all done by the time the /etc/emacs startup files are run. That > > way. add entries at the tail end of the load-path would indeed yield > > the expected result. For everybody. Not just me. > > Its load-path is already 'all done' by the time the Debian startup > scripts run, or things would break in horrible ways. > > Your problem is that this code from debian-startup.el (in the > `debian-run-directories' function) stores the original load-path before > running the scripts and then explicitly overwrites load-path, adding any > items added by the Debian startup scripts at the head of the original > load-path: > > ,---- > | ;; restore the old load-path -- including any new paths added by > | ;; files loaded in directory traversal. > | (let ((add-on-package-paths > | (delq nil (mapcar > | (lambda (item) > | (if (not (member item new-path)) > | item > | nil)) > | load-path)))) > | (setq load-path (append add-on-package-paths old-load-path)))))) > `---- Well, I'm sure that was done for a valid reason. But isn't it horribly broken? It means we can't do what's best for the load-path. > This is why your site-lisp directory added at the end of the load-path > in emacs-goodies-el's startup script ends up being moved before the > system load path items after `debian-startup' returns. > > So, we could try to fix emacsen-common by changing this code, or we > could try my (admittedly cumbersome) symlink solution... If I have to resort to the symlink solution, everybody who gets this problem will have to do the same thing. If emacsen-common gets fixed, it's fixed for everybody! How likely it is that we can get emacsen-common fixed? That package has seen a single upload since `oldstable' (woody?) I'd rather REMOVE /usr/share/emacs/site-lisp/emacs-goodies-el from the load-path altogether, except that breaks the ability to jump to the code when viewing variables and functions via `C-h v' and `C-h f'. Much easier and cleaner than maintaining a collection of symlinks... Peter -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]