Disable org until user-config

[tonyday567]

From the org layer README:

Since version 0.104, spacemacs uses the `org` version from the org ELPA
repository instead of the one shipped with emacs. Then, any `org` related code
should not be loaded before `dotspacemacs/user-config`, otherwise both versions
will be loaded and will conflict.

It's a real gotcha, as both versions of org load silently, and you get errors down the track, a lot of which I'm seeing on gitter. Function definition and use-package setup are both fine as they don't instantiate org in any way - it's the imperative code bits that are the problem.

Can we disable org completely during the layer configuration phase? The problem will keep cropping up if we don't.

[syl20bnr]

I'm not sure how we can do it.
Users should not put stuff in user-init that require packages but how to force this ?

[StreakyCobra]

Users should not put stuff in user-init that require packages but how to force this ?

We can first change the documentation to not encourage people putting any user code there 😂

Initialization function for user code.
It is called immediately after `dotspacemacs/init'. You are free to put any
user code."

[tonyday567]

In configuration-layer//load-packages, after installing packages but before configuring packages, you could check whether org is already on the package-activated-list, and throw an error if it is?
I don't know much about the load process but, so may well have missed something. It probably wouldn't work for refreshes so you'd need something to tell whether you're starting up or not.

[syl20bnr]

Checking if org has been required before actually loading it via the layer system is a good idea 👍

[hsitz]

I seem to have had experience with related issue. I was having issues with org agenda working (void variables issue). At this point was working with org files but with no org layer enabled. Turned out that org was not present in elpa dir at all, seems built-in version was being used. After having deleted the built-in version I again tested. Org doesn't work at all in this case if org layer is not enabled, since no org is loaded in elpa. I manually loaded to elpa and it was deleted on startup as an orphan file. After enabling org layer the org packages load and seem to work. However, now my which-key doesn't work. I toggle which-key from enabled to disabled and back again and can never get the which-key menu to pop up. I'm using Ubuntu 14.1 and Emacs 24.3, if that matters.

[tonyday567]

Just a wild hunch, but I would expect that deleting the builtin org-mode could lead to very unexpected behaviour at a really low level - but that's just a hunch.
I think you arrived at the right solution - enable org layer (and don't put org code up the front of the load process).

[hsitz]

I assume you'd want to have an org package in load-path somewhere, but if it's in elpa I don't expect any issue if built-in org is missing; it's a complete shadowing. My solution isn't really satisfactory, given that which-key doesn't work. So for now I expect I'll be going back to pre-spacemacs setup, where I had elpa version of org working fine.

[hsitz]

Also, a note regarding the README in org layer directory, which contains several snippets of elisp that are supposed to be placed in .spacemacs file. There are no instructions exactly regarding where those snippets should be placed. I assume it matters, but even if it doesn't then that should be stated explicitly. Also, it would be good idea to place comment in .spacemacs alerting user that lines should be added to .spacemacs if org layer is enabled.

[TheBB]

I am not satisfied with the current solution because it appears to fire warnings when packages are being installed, presumably because org must be loaded to compile those packages.

It also doesn't work with syncing layers. See: #3933

I will disable the check until we figure out how to do this properly.

[tonyday567]

Good call.

For reference, the builtin version is currently 8.2.10 and elpa is 8.3.2. The warnings that @autosquid posted on #3933 is the current signpost that 8.2.10 (the builtin) has loaded, but this changes as the elpa package evolves.

For syncing, org-version could be used to test which org is loaded before issuing the error. Locate-library etc can't be used however, as the elpa org is higher on load-path and will be returned even if builtin is loaded.

There is unload-feature which I've never tried, and the docs make it sound a bit risky.

Then there is making org special and loading the org layer early if it exists (eg before packages). This leads to including org within the core distribution - and an extra 4 seconds or so added to load time. Though you could still have lazy loading when org isn't used on load.

[github-actions]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Please let us know if this issue is still valid!