Dependency Heck

How I broke my Emacs and taught myself a lesson.

What Could Go Wrong?TM

Last night my Emacs config was acting squirrely and I decided a clean install was in order. So I ran some commands:

$ rm -rf ~/.emacs.d
$ git clone --depth 1 https://github.com/hlissner/doom-emacs ~/.emacs.d
$ ~/.emacs.d/bin/doom install

You know how beginners are taught to be cautious when using rm -rf? Sometimes, hubris or plain old forgetfulness sends those early lessons flying out the window.

And so, instead of a seamless rebuild experience, I was met with this:

fatal: unable to access 'https://git.savannah.gnu.org/git/emacs/org-mode.git/': SSL certificate problem: certificate has expired
[Return code: 128]

This may actually be due to gnu.org forgetting to renew their certificate, or (more likely) it might be a problem with my setup. Regardless, I needed a workaround.

I could learn to hack the internals of doom’s installation and package managemnt, but that did not sound enjoyable. So, I tried installing spacemacs instead. I worked with spacemacs for a bit, but fixing doom started to sound better, so I went into doom’s .emacs.d/modules/lang/org/packages.el and commented the line regarding org-contrib. In the end, these were my changes:

diff --git a/modules/lang/org/packages.el b/modules/lang/org/packages.el
index 37163eb..ce4c28e 100644
--- a/modules/lang/org/packages.el
+++ b/modules/lang/org/packages.el
@@ -3,7 +3,7 @@

 (package! org
   :recipe (:host nil
-           :repo "https://git.savannah.gnu.org/git/emacs/org-mode.git"
+           :repo "git://git.sv.gnu.org/emacs/org-mode.git"
            :files (:defaults "etc")
            ;; HACK Org requires a post-install compilation step to generate a
            ;;      org-version.el with org-release and org-git-version
@@ -18,7 +18,7 @@
                              (cdr (doom-call-process "git" "rev-parse" "--short" "HEAD")))
                      "(provide 'org-version)\n")))
   :pin "cc2490a7061955395c4f5a1a23a088044554a2f7")
-(package! org-contrib :pin "b8012e759bd5bf5da802b0b41734a8fec218323c")
+;; (package! org-contrib :pin "b8012e759bd5bf5da802b0b41734a8fec218323c")

 (package! avy)
 (package! htmlize :pin "dd27bc3f26efd728f2b1f01f9e4ac4f61f2ffbf9")

This allowed me to install doom. However, some stuff was is still missing. I rediscovered an old bug that I had worked around previously, but this time the load path was wrong. Emacs was looking in homebrew’s org/lisp directory, rather than in .emacs.d/.local/straight. So clearly my setup is all messed up.

But my “process” with Emacs is to flail around randomly until things work for my particular use case. More hacks ensued:

First, I added org-contrib in .doom.d/packages.el, using a different recipe from the default which I commented out above:

(package! org-contrib
  :recipe (:host github :repo "emacsmirror/org-contrib"))

Then I fixed the weirdness of ob-J.el not providing the right symbol:

;; file /usr/local/Cellar/emacs-mac/emacs-27.2-mac-8.2/share/emacs/27.2/lisp/org/ob-J.el.gz
(provide 'ob-J)
+ (provide 'ob-j)

Then M-x byte-compile-file RET to update the corresponding .elc file. Phew.

Lessons Learned

  1. make backups
  2. Emacs is quirky and not always delightful, but it is very forgiving and hackable