Colin Baxter <m43...@yandex.com> writes:
> Recently, if I use C-c C-x ! to refresh org-mode after a git pull, I get an
> error. I then have to close down emacs and launch again. This rather
> defeats the object of C-c C-x !. This appears to have happened only recently
>
> The Backtrace is
>
> --8<---------------cut here---------------start------------->8---
> Debugger entered--Lisp error: (error "Org version mismatch. Make sure that
> correct `loa...")
> (signal error ("Org version mismatch. Make sure that correct `loa..."))
> (error "Org version mismatch. Make sure that correct `loa...")
> (byte-code "\300\301!\210\302
> \303\232\204\23\0\304\305!\210\306\307!\210\300\301!\210\300\310!\210\300\311!\210\300\312!\210\300\313!\210\300\314!\210\300\315!\210\300\316!..."
> [require org-macs org-git-version "release_9.5.5-821-g9bd8a9" warn "Org
> version mismatch. Make sure that correct `loa..." error "Org version
> mismatch. Make sure that correct `loa..." org-compat org-keys ob-eval
> ob-core ob-comint ob-exp ob-table ob-lob ob-ref ob-tangle provide ob] 2)
> (load "/home/redknight/git/org-mode/lisp/ob" noerror nil nil mustsuffix)
> (#f(compiled-function (f) #<bytecode -0x5dfc25d>) "ob")
> (mapcar #f(compiled-function (f) #<bytecode -0x5dfc25d>) ("ob" "ob-C"
> "ob-R" "ob-awk" "ob-calc" "ob-comint" "ob-core" "ob-ditaa" "ob-dot"
> "ob-emacs-lisp" "ob-eshell" "ob-eval" "ob-exp" "ob-fortran" "ob-gnuplot"
> "ob-latex" "ob-lisp" "ob-lob" "ob-org" "ob-perl" "ob-plantuml" "ob-python"
> "ob-ref" "ob-ruby" "ob-shell" "ob-sql" "ob-sqlite" "ob-table" "ob-tangle"
> "obarray" "oc" "oc-basic" "oclosure" "ol" "ol-bbdb" "ol-bibtex" "ol-docview"
> "ol-eshell" "ol-eww" "ol-gnus" "ol-info" "ol-irc" "ol-mhe" "ol-rmail"
> "ol-w3m" "org-agenda" "org-capture" "org-collector" "org-compat" "org-crypt"
> ...))
> (org-reload nil)
> (funcall-interactively org-reload nil)
> (call-interactively org-reload)
> (popup-menu (keymap "Global Menu" ... ... ... ... ... ... ... "menu-bar"
> keymap "Org Mode Menu" ... keymap ...) f10)
> (x-menu-bar-open nil)
> (menu-bar-open nil 1)
> (funcall-interactively menu-bar-open nil 1)
> (call-interactively menu-bar-open nil nil)
> (command-execute menu-bar-open)
> --8<---------------cut here---------------end--------------->8---
>
>
> I also receive a warning, copied below. I do not use 'packages' but use
> org-mode from a git repository and have done so with no previous issues.
>
> --8<---------------cut here---------------start------------->8---
> ⛔ Warning (emacs): Org version mismatch. Make sure that correct `load-path'
> is set early in init.el
> This warning usually appears when a built-in Org version is loaded
> prior to the more recent Org version.
>
> Version mismatch is commonly encountered in the following situations:
> 1. Emacs is loaded using literate Org config and more recent Org
> version is loaded inside the file loaded by `org-babel-load-file'.
> `org-babel-load-file' triggers the built-in Org version clashing
> the newer Org version attempted to be loaded later.
>
> It is recommended to move the Org loading code before the
> `org-babel-load-file' call.
>
> 2. New Org version is loaded manually by setting `load-path', but some
> other package depending on Org is loaded before the `load-path' is
> configured.
> This "other package" is triggering built-in Org version, again
> causing the version mismatch.
>
> It is recommended to set `load-path' as early in the config as
> possible.
>
> 3. New Org version is loaded using straight.el package manager and
> other package depending on Org is loaded before straight triggers
> loading of the newer Org version.
>
> It is recommended to put
> (straight-use-package 'org)
> early in the config. Ideally, right after the straight.el
> bootstrap. Moving `use-package' :straight declaration may not be
> sufficient if the corresponding `use-package' statement is
> deferring the loading.
> --8<---------------cut here---------------end--------------->8---
>
I wasn't aware that command even existed. However, I suspect it will
cause issues in your use case. I'm not sure it is a good command to
actually have given the complexities associated with getting a clean org
build.
In many cases, you may not run into issues - especially if you do a git
pull frequently. However, I can see various scenarios which will lead to
inconsistent builds. I suspect the error you are seeing is the result of
recent work to try and identify builds which are likely to result in an
inconsistent 'mixed' version build. Detecting such scenarios is
difficult and relies on a number of heuristics, one of which is to flag
a problem if the loaded version and the target build version don't
match.
A lot would depend on how you build (re-compile) org mode after doing a
git pull. If you compile it in a separate Emacs instance, you should
have less issues and reloading after the build will likely
work. However, if your trying to build org mode within the running Emacs
where you have already loaded org mode, I suspect you will run into
issues. You have a slight 'chicken and egg' issue and will run into
similar issues as the common mixed build problems.
One thing which might work would be to ensure you run the reload command
with the option to load from uncompiled sources BEFORE you run the build
process and then re-run the load command after the build (loading
compiled versions this time).
I have no idea how things might break given the new native compilation
modes in Emacs. I suspect it will cause all sorts of issue with your
workflow.
Personally, I always update org in a fresh instance of Emacs (before any
org functionality is loaded) and I would always restart Emacs after
updating a major packages like org mode. I'm not sure why we have the
reload command - I suspect it may be a hang over from earlier attempts
to work around the mixed build problem. I do suspect that given new
native compilation modes and the additional complexity ths can cause,
combined with increasing org mode complexity, the notion of being able
to pull down a new version, build and reload it within one emacs
instance is perhaps flawed or at the very least, is more complex than
just forcing a reload of org *.elc files. .
