From: Tim Cross <theophilusx@gmail.com>
To: emacs-orgmode@gnu.org
Subject: Re: refresh not working for org-mode from git
Date: Sat, 24 Sep 2022 11:12:18 +1000 [thread overview]
Message-ID: <86sfkhmu1l.fsf@gmail.com> (raw)
In-Reply-To: <87illec6qa.fsf@yandex.com>
Colin Baxter <m43cap@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. .
next prev parent reply other threads:[~2022-09-24 1:38 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-09-23 17:59 refresh not working for org-mode from git Colin Baxter
2022-09-24 1:12 ` Tim Cross [this message]
2022-09-24 8:14 ` Colin Baxter
2022-09-24 3:22 ` Ihor Radchenko
2022-09-24 8:19 ` Colin Baxter
2022-09-24 9:31 ` Colin Baxter
2022-09-26 14:34 ` Ihor Radchenko
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.orgmode.org/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=86sfkhmu1l.fsf@gmail.com \
--to=theophilusx@gmail.com \
--cc=emacs-orgmode@gnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).