Re: Fwd: errors when using org-agenda

[Tim Cross <theophilusx@gmail.com>]

Greg Minshall <minshall@umich.edu> writes:

> Tim, et al.,
>
>> These types of errors are frequently caused by a 'mixed' installation
>> of org versions. This will happen if you upgrade org when org is
>> already loaded in the instance of emacs used to perform the upgrade.
>
> a question: is there any way that we can, as org starts up, detect
> either the actuality, or possibility, of a mixed installation?
> maybe something like
> ----
> (assert (eq 1
>             (length
>              (seq-filter
>               (lambda (d) (file-exists-p (concat d "/" "org.el")))
>               load-path))))
> ----
> or some such?  (well, maybe fail in a more user-friendly way... :)
>
I'm not sure auto detecting is possible. It isn't so much about what
files exist, but what functions are already defined and/or what
libraries are already loaded when the upgrade process tries to compile
the new version. The 'mixed' refers to the resulting *.elc files, which
havbe been compiled with definitions from two different org versions.
With package.el for example, once the upgrade has been completed, the
old ELPA version doesn't exist anymore, so it isn't as simple as just
checking for multiple references to org source files in the load path
and at different locations.

What would really be needed is some way to check when org is going to be
compiled that no existing org functionality is loaded. Doubt this can be
easily done within org itself because of a chicken and egg problem - you
would have to load org to run the code to check if org is loaded.

It could be possible to add something to the package installer, but that
would mean doing something with all the package installers e.g.
package.el, straight.el, etc.

Some distributions, like spacemacs, manage this by separating marking of
packages to be upgraded and doing the upgrade into separate sessions.
You check for updates, write the list of packages to be updated, move
the existing packages to a recovery area and then you have to restart
Emacs. On restart, the list of packages to be upgraded (it is really an
install because the previous versions have been moved out into a
separate 'recovery' area) and if org is in the list, move it to the
front of the list so that it is installed before any other packages (to
protect against other packages loading org as part of their
installation).

All this means, with spacemacs, you can be pretty confident an upgrade
will work without the mixed install issue. Even better, if the upgraded
package has problems and you want to downgrade back to the previous
version, that is supported as well.

The bad aspect of spacemacs is that after you have used it for a while,
your pretty much ruined when it comes to running vanilla Emacs. You get
very use to the VI style modal editing and find it hard to use emacs
without evil mode installed.