2

I have a bunch of packages installed. One of them is adding ~/.emacs.d to my load-path, which Emacs is (unsurprisingly) complaining about.

I could be incorrect here, but:

Attempting to bisect my set of packages is a slow work, because I'd have to uninstall all my packages, and then re-install only half of them, which means downloading, and a lot of fairly manual work.

Is there an easier way to determine which package is setting the value of load-path?

Extra information:

  • This doesn't happen when loading emacs with -Q.
  • I've not changed my config between it working and breaking, only upgrade packages
  • This doesn't happen if I run emacs without a site-file (--no-site-file), regardless of whether I add --no-site-lisp I confused my flags here.
  • This doesn't happen if run emacs with --no-init-file. site-file / site-lisp have no effect
  • GNU Emacs 24.4.2 (x86_64-unknown-linux-gnu, GTK+ Version 3.10.8) of 2015-03-31
  • Bug Hunter tells me that package-initialise is to blame
  • grep -aR "'load-path" ~/.emac.d/elpa --include '*el' | egrep -v ':[[:space:]]*;+' | fgrep -v "(add-to-list 'load-path (or (file-name-directory #$) (car load-path)))" gives no results
  • Removing all my .elc files in ~/.emacs.d/elpa appeared to fix this problem, although it's not a great solution. I'm not going to submit & accept because I've no idea how works or whether it's really a fix. This is easily done with find ~/.emacs.d/elpa -name '*.elc' -delete
Improve this question
10
  • 2
    It's very surprising if any package is doing that. I wouldn't think they have any business adding anything outside of their own ~/.emacs.d/elpa/ sub-directories to the load-path. Could you at least confirm to us that it's not your init file (or any other start-up library), by commenting out all of its contents and then running emacs --no-site-file --no-site-lisp and checking the value of load-path? (Offhand I'm not sure whether using emacs -q inhibits elpa packages or not.)
    – phils
    May 5 '15 at 11:38
  • Another suggestion: If this behavior started only recently, try to remember what packages you last added to your setup (checking timestamps of packages in your elpa directory should help), and what parts of your init-file you recently changed. If you are using a version control system to keep track of changes to your config, this is trivial -- all you need to do is have a look at the most recent commits.
    – itsjeyd
    May 5 '15 at 13:27
  • I have the same problem; please post the actual answer (not just the grep/bisect suggestions) when you find it!
    – sds
    May 5 '15 at 14:42
  • Could you explain what makes you think it comes from a package, and what do you mean by such a package (do you mean an ELPA package, or just an Elisp package installed by hand)?
    – Stefan
    May 6 '15 at 3:07
  • (1) Try grepping for load-path without the quote, there are plenty of ways to modify a variable without quoting the name. (2) If that doesn't work, also try grepping the elc files. Grep will think they're binary files, but it'll still tell you which ones match. (3) In case you end up having to check packages one-by-one: I grepped my elpa and both python-mode and w3m made suspicious use of the load-path. I'm not saying they're wrong, I'm just saying I would start with them.
    – Malabarba
    May 15 '15 at 12:33
3

Two approaches come to mind.

Use rgrep

... to search for offending code:

  1. Open your elpa directory in Dired. If you're not sure where this directory is located, check the value of package-user-dir with C-h v.

  2. Call rgrep:

    M-x rgrep RET add-to-list 'loadpath RET *.el RET RET

    You might need to play around with the exact search string a bit to narrow down the list of results.

Use package-load-list

... to control which packages are loaded:

  1. Check the value of package-activated-list to get a list of packages that are currently activated.

  2. Add the following code to your init-file:

    (setq package-load-list '((magit nil) (multiple-cursors nil) ...))

    Replace (magit nil) (multiple-cursors nil) ... with about half of the packages that are currently activated. (Note that nil means "load the latest version" in this context.) Emacs will load all packages that you list at startup and ignore the remaining packages.

  3. Restart Emacs to see if the error persists. If it does, keep bisecting the list of packages you are loading until you are left with the package that is causing the problem.

Improve this answer
8
  • Hmm, this is happening even when I comment out my entire init.el. It also happens when I set my package-load-list to nil
    – Squidly
    May 5 '15 at 12:26
  • @MrBones A couple more ideas: 1. What is the value of user-init-file? Make sure it points to the correct file. 2. What happens when you start Emacs via emacs -Q? 3. What is the exact error/warning message you are getting?
    – itsjeyd
    May 5 '15 at 13:10
  • 1.) User init is correct 2) Nothing interesting happens with -Q. I get a vanilla emacs. 3) Your 'load-path' seems to contain your '.emacs.d' directory: ... and if I inspect-variable on load-path, sure enough my .emacs.d is in there
    – Squidly
    May 5 '15 at 13:18
  • @MrBones What happens when you do M-x package-initialize RET right after starting Emacs via emacs -Q?
    – itsjeyd
    May 5 '15 at 13:29
  • Nothing. No packages are loaded
    – Squidly
    May 5 '15 at 13:37
3

The Bug-Hunter may be able to help you with that.

  1. Install the bug-hunter package from the Package-Menu.
  2. Invoke M-x bug-hunter-init-file

  3. It will ask you for an assertion, type (or paste) in the following predicate and hit RET.

    (or (member "~/.emacs.d/" load-path)
    (member (expand-file-name "~/.emacs.d/") load-path))

That's it! You'll be presented with a buffer reporting the results, similar to this one:
cl
(this run was testing which package was doing a (require 'cl))

Things to consider

The bug-hunter can only analyse your init file, so if the problem is happening during autoloading time, then it's only going to blame (package-initialize) (which is not very useful).

On the other hand, if it happens during package require time, if it's something else in your init file, or if it's something in the site-files, the Bug-Hunter should give some relevant information.

Improve this answer
6
  • Unfortunately, it's happening during (package-initialize), but nice tool
    – Squidly
    May 6 '15 at 9:16
  • @MrBones shame :-(. Then it's probably an autoload file in your Elpa subdir.
    – Malabarba
    May 6 '15 at 9:38
  • This feels like a bug. If I start emacs with a commented out config from inside my .emacs.d folder I get the error message. If I start emacs in my .emacs.d folder with -q I don't get the error.
    – Jordon Biondo
    May 12 '15 at 13:50
  • @JordonBiondo If you comment out your configs then installed packages will still be initialized. If you start with -q they won't. That means this is being caused by a package autoload.
    – Malabarba
    May 12 '15 at 14:00
  • regardless of whether package-initialize is called?
    – Jordon Biondo
    May 12 '15 at 14:39
2

Adding 

(setq load-path (cl-delete-if-not #'file-name-absolute-p load-path))

to my .emacs.el fixed this problem for me.

The problem manifests itself unless I pass the --no-site-lisp option.

I filed a bug report.

Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.