Re: refresh not working for org-mode from git
Colin Baxter writes: > The solution is to use `make autoloads'. I suppose that should have been > obvious to me at the beginning. After git pull (`+' in vc-dir) the > working recipe is: FYI, the versions checks are less strict now to work around some Emacs limitations. See https://list.orgmode.org/orgmode/jwvczc05u7r.fsf-monnier+em...@gnu.org/ Though I'd still advice to run make autoloads && make if you can. -- Ihor Radchenko, Org mode contributor, Learn more about Org mode at https://orgmode.org/. Support Org development at https://liberapay.com/org-mode, or support my work at https://liberapay.com/yantar92
Re: refresh not working for org-mode from git
The solution is to use `make autoloads'. I suppose that should have been obvious to me at the beginning. After git pull (`+' in vc-dir) the working recipe is: 1. rm *.elc 2. Update in org-mode buffer using C-c C-x ! 3. make clean 4. make autoloads 5. Check update org-mode via C-c C-x! 6. make 7. Check update org-mode again via C-c C-x! Some of these steps might not be necessary. I will experiment. Thank you all again for your help. Best wishes, Colin.
Re: refresh not working for org-mode from git
Dear Ithor, > Ihor Radchenko writes: > Colin Baxter 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 > Does it help if you run make after git pull? I will certainly try that and miss out `make clean', at least in the first round. As I said in the email to Tim, I will try various combinations in the build process. Thank you for your reply. Best wishes, Colin.
Re: refresh not working for org-mode from git
Thank you for your detailed reply. > Tim Cross writes: > Colin Baxter 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 - snip - > 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. That could well be the case here because the technique used to work up until quite recently (~2 weeks) > 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. Normally, I use `M-x vc-dir' to update from git, then `M-x compile' followed by `make clean' and `make'. Finally, update org-mode in the same emacs with an org-mode buffer present. As I said, it used to work well. > 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). Yes, I will try that. And I will also ring all the other changes to see what happens --- if anything. > 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. I have avoided problems here by not using native compilation. I did try it once in the past, but I didn't think it was worth the candle since frankly I didn't notice any change in emacs performance, possibly because I only do simple things with emacs. > 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. Indeed. Emacs seems to have became a rather complex beast in recent years. Perhaps it was ever thus. Best wishes, Colin.
Re: refresh not working for org-mode from git
Colin Baxter 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 Does it help if you run make after git pull? -- Ihor Radchenko, Org mode contributor, Learn more about Org mode at https://orgmode.org/. Support Org development at https://liberapay.com/org-mode, or support my work at https://liberapay.com/yantar92
Re: refresh not working for org-mode from git
Colin Baxter 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) #) "ob")
> (mapcar #f(compiled-function (f) #) ("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 mod
