Greg Minshall <minsh...@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.