If you’re an Emacs user and have a non-trivial .emacs or init.el you have almost certainly run into the situation where you make a change or upgrade a package or Emacs and things stop working. I see questions about how to troubleshoot this from n00bs all the time.
Invariably, the advice is to do a binary search on your configuration file by commenting out half of it and seeing if the errors persists and then commenting out half of the other half if so. That process converges in \(\log_{2} \,n\) time for \(n\) lines. That’s pretty quickly for most .emacs or init.el files but is still a pain.
Happily, the prolific Artur Malabarba—when does he have time to work on his thesis?—has come to the rescue with elisp-bug-hunter. If you get an error while loading Emacs, just run
M-x bug-hunter-init-file RET RET
and bug-hunter will do the binary search for you. You’ll get a nice report showing where the error occurred. That’s pretty nice but bug-hunter is even more flexible. Suppose Emacs loads without error but some aspect doesn’t work correctly. If you can write an assertion to detect the error, bug-hunter can still find the problem.
The example Malabarba gives is figuring out how cl.el is getting loaded. To do that, you just run
M-x bug-hunter-init-file RET (featurep 'cl) RET
and bug-hunter will tell you where it’s getting loaded. That very issue has come up with my own init.el file so I ran that example and discovered that package-initialize was loading the library. That’s very nice indeed. Malabarba gives other examples in the README at the link.
I’ve loaded bug-hunter now so that it will be available the next time I need it. You could probably get it loaded after the fact but why make life harder than it needs to be?