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.