4
votes

Background

Spacemacs documentation recommends that you wrap additional org-mode configurations in (with-eval-after-load 'org [...config...]):

(defun dotspacemacs/user-config ()
  (with-eval-after-load 'org
   ;; here goes your Org config
   ))

This is because:

Since version 0.104, spacemacs uses the org version from the org ELPA repository instead of the one shipped with emacs. [...] Because of autoloading, calling to org functions will trigger the loading up of the org shipped with emacs which will induce conflicts.

But lets say you then want to use some-package that configures org-mode in various ways. The org-related function inside the some-package.el file are not wrapped in with-eval-after-load. This is true for most org-related packages, which just have a require org statement at the top.

How then do you load some-package so that it does not conflict with spacemacs's org implementation? My first though was to do this [A]:

(defun dotspacemacs/user-config ()
  (with-eval-after-load 'org
   (require 'some-package)
   ;;configure 'some-package and 'org-mode
   ))

Is this the correct approach? Also, if you follow this route for Melpa packages, Spacemacs will delete and reinstall the package every-time you evaluate your dotfile. To avoid this, the Melpa package has to first be added to [B]

(defun dotspacemacs/layers ()
  (setq-default
    dotspacemacs-additional-packages '(some-package)
   ))

Question

In general, will this code ([A][B]) ensure that my some-package (which provides customizations for org) does not mess with spacemacs' org implementation? Or do I actually have to edit the some-package.el file directly and wrap its org-related functions in with-eval-after-load (hope not)? Or some other way?

update

I was told on gitter chat that its safe to do dotspacemacs-additonal-packages and with-eval-after-load as outlined above. So that's the solution.

Note

For reference, That somepackage is here (it's not a Melpa package so [B] does not apply in this partuclar case), but my question is more of a general one.

1
For reference, this question was also raised here.Drew
".... most org-related packages ... assume you're using the org version shipped with Emacs": AFAIK, they do not assume that: they assume that there is an org that they can use (which may or may not be true). If there is no org-mode loaded and you load such a package and it calls an autoloaded org function, it will try to load the default org shipped with emacs (which may cause a "mixed installation" if you then load ELPA-org somehow). But if you have ELPA-org already loaded and able to satisfy any requires, then there should be no problem: the emacs-supplied org will never be touched.NickD

1 Answers

1
votes

I did not find out how to load the file from github, this is what I am doing now.

  (with-eval-after-load 'org
    (load-file "~/.emacs.d/private/scimax-org-babel-ipython.el"))

I have also tried the code below, but it downloads every time and delays the startup, there might have been some other problems

(scimax-org-babel-ipython :location (recipe :fetcher github :repo "jkitchin/scimax") :files ("scimax-org-babel-ipython.el"))

The scimax library is pretty solid, I hope that the author will put it on melpa in the future.

A word of warning: Changing any org settings before the correct org has been loaded will trigger a load of the wrong org version. This will completely mess up the installation. The only way to fix this was to remove all .elc files in the elpa folder. I made the mistake when trying to load the files above, as they change org settings they will trigger a load. This problem manifests itself in strange warnings, like variable void or similar.