org-mode is broken after restarting emacs on latest develop when emacs < 29
#15896
Comments
|
Confirmed. At first my emacs was working fine. But after deleting the two packages mentioned above, Emacs won't start properly. (spacemac-buffer won't show up since it requires org with my settings) |
|
Inspired by https://irreal.org/blog/?p=10999 To fix it:
(require 'package)
(add-to-list 'package-archives '("melpa" . "https://melpa.org/packages/"))
(setq package-user-dir
(expand-file-name "develop"
(expand-file-name emacs-version
(expand-file-name "elpa"
user-emacs-directory))))
(package-refresh-contents)
(package-install 'org)
|
|
@lebensterben I followed your workaround but looks it didn't work for me. I did I just followed your exact instruction and haven't dug into the blog post. I will check what's going on later. One thing I noticed is that, |
|
make sure you removed all org-9.6* in your elpa directory. |
|
Strange, this seems only to happen on emacs 28, not on emacs 29 and it seems to be independent from what is entered into the spacemacs buffer, setting it to show no content at all (no lists no agenda) has the same effect. When I am trying to require org in my dotfile I am seeing the following: Debugger entered--Lisp error: (invalid-function org-assert-version)
org-assert-version()
byte-code("\300\301!\210\302 \210\300\303!\210\300\304!\207" [require org-macs org-assert-version cl-lib oc] 2)
#<subr require>(org-keys)
apply(#<subr require> org-keys)
require(org-keys)
eval-buffer(#<buffer *load*> nil "/home/smile13241324/.emacs.d/elpa/28.2/develop/org..." nil t) ; Reading at buffer position 3557
load-with-code-conversion("/home/smile13241324/.emacs.d/elpa/28.2/develop/org..." "/home/smile13241324/.emacs.d/elpa/28.2/develop/org..." nil t)
#<subr require>(org)
apply(#<subr require> org)
require(org)
(progn (require 'org))
eval((progn (require 'org)) t)
elisp--eval-last-sexp(nil)
#f(compiled-function (eval-last-sexp-arg-internal) "Evaluate sexp before point; print value in the echo area.\nInteractively, with a non `-' prefix argument, print output into\ncurrent buffer.\n\nThis commands handles `defvar', `defcustom' and `defface' the\nsame way that `eval-defun' does. See the doc string of that\nfunction for details.\n\nNormally, this function truncates long output according to the\nvalue of the variables `eval-expression-print-length' and\n`eval-expression-print-level'. With a prefix argument of zero,\nhowever, there is no such truncation.\nInteger values are printed in several formats (decimal, octal,\nand hexadecimal). When the prefix argument is -1 or the value\ndoesn't exceed `eval-expression-print-maximum-character', an\ninteger value is also printed as a character of that codepoint.\n\nIf `eval-expression-debug-on-error' is non-nil, which is the default,\nthis command arranges for all errors to enter the debugger." (interactive "P") #<bytecode -0x45c973c4e971b99>)(nil)
#f(compiled-function (&rest _it) #<bytecode 0x1fff02a74872>)()
eval-sexp-fu-flash-doit-simple(#f(compiled-function (&rest _it) #<bytecode 0x1fff02a74872>) #f(compiled-function (&rest args2) #<bytecode -0x1133d5a2cfbd057f>) #f(compiled-function (&rest args2) #<bytecode -0x112bf59b0182057f>))
eval-sexp-fu-flash-doit(#f(compiled-function (&rest _it) #<bytecode 0x1fff02a74872>) #f(compiled-function (&rest args2) #<bytecode -0x1133d5a2cfbd057f>) #f(compiled-function (&rest args2) #<bytecode -0x112bf59b0182057f>))
esf-flash-doit(#f(compiled-function (&rest _it) #<bytecode 0x1fff02a74872>) #f(compiled-function (&rest args2) #<bytecode -0x1133d5a2cfbd057f>) #f(compiled-function (&rest args2) #<bytecode -0x112bf59b0182057f>) #f(compiled-function (&rest args2) #<bytecode 0x153e757edc0c5a87>))
ad-Advice-eval-last-sexp(#f(compiled-function (eval-last-sexp-arg-internal) "Evaluate sexp before point; print value in the echo area.\nInteractively, with a non `-' prefix argument, print output into\ncurrent buffer.\n\nThis commands handles `defvar', `defcustom' and `defface' the\nsame way that `eval-defun' does. See the doc string of that\nfunction for details.\n\nNormally, this function truncates long output according to the\nvalue of the variables `eval-expression-print-length' and\n`eval-expression-print-level'. With a prefix argument of zero,\nhowever, there is no such truncation.\nInteger values are printed in several formats (decimal, octal,\nand hexadecimal). When the prefix argument is -1 or the value\ndoesn't exceed `eval-expression-print-maximum-character', an\ninteger value is also printed as a character of that codepoint.\n\nIf `eval-expression-debug-on-error' is non-nil, which is the default,\nthis command arranges for all errors to enter the debugger." (interactive "P") #<bytecode -0x45c973c4e971b99>) nil)
apply(ad-Advice-eval-last-sexp #f(compiled-function (eval-last-sexp-arg-internal) "Evaluate sexp before point; print value in the echo area.\nInteractively, with a non `-' prefix argument, print output into\ncurrent buffer.\n\nThis commands handles `defvar', `defcustom' and `defface' the\nsame way that `eval-defun' does. See the doc string of that\nfunction for details.\n\nNormally, this function truncates long output according to the\nvalue of the variables `eval-expression-print-length' and\n`eval-expression-print-level'. With a prefix argument of zero,\nhowever, there is no such truncation.\nInteger values are printed in several formats (decimal, octal,\nand hexadecimal). When the prefix argument is -1 or the value\ndoesn't exceed `eval-expression-print-maximum-character', an\ninteger value is also printed as a character of that codepoint.\n\nIf `eval-expression-debug-on-error' is non-nil, which is the default,\nthis command arranges for all errors to enter the debugger." (interactive "P") #<bytecode -0x45c973c4e971b99>) nil)
eval-last-sexp(nil)
funcall-interactively(eval-last-sexp nil)
call-interactively(eval-last-sexp nil nil)
command-execute(eval-last-sexp)
I think we need more investigation into this first. |
|
I had to explicitly set the (require 'package)
(add-to-list 'package-archives '("melpa" . "https://melpa.org/packages/"))
(setq package-user-dir "/home/localuser/.emacs.d/elpa/28.2/develop/")
(package-refresh-contents)
(package-install 'org) |
|
For me running
and then starting Emacs was enough. Spacemacs then reinstalled org and everything was fine. |
|
There has been many problems like this over the years due to org mode. Emacs comes with org mode, but almost always folks need to install a newer version. This newer version is also needed by other packages as well. That is why I make sure that org package is installed very early on in |
Note that in my case, alongside the existing package directory (e.g. ~/.emacs.d/elpa/develop) the upper snippet downloads and installs all packages into the
|
|
have you first removed org from elpa directory? |
|
I don't think org package is in melpa. You need to add https://elpa.gnu.org/packages/. Following is how spacemacs sets up packages. (defun configuration-layer/create-elpa-repository (name output-dir)
"Create an ELPA repository containing all packages supported by Spacemacs."
(configuration-layer/make-all-packages 'no-discover)
(let (package-archive-contents
(package-archives '(("melpa" . "https://melpa.org/packages/")
("gnu" . "https://elpa.gnu.org/packages/")
("nongnu" . "https://elpa.nongnu.org/nongnu/"))))
|
|
if one followed my instructions melpa is added. |
|
FWIW, removing the byte-compiled *.elc files in the installed elpa org directory seems to fix the org-assert-function issue for me (but I use standard emacs not spacemacs). |
|
Corrupt byte compiled files could result if you installed org package after already having loaded built-in org.el. I think this is the most common problem with org mode the folks have had over the years. |
|
@emacs18 will there be any impact on loading time? |
|
I don't think so, but I am not sure. Even if startup time is longer, I could tolerate it if that prevents hard to debug errors. |
|
I think this might get fixed by deleting all of |
|
@tko I just tested and it doesn't solve the problem for me 😞 |
Running your snippet returns "‘org’ is already installed" Yes, even deleted the complete elpa folder. Tried even deleting @lebensterben ..and of course: Thank you very much for your time 🙏 |
|
what's your emacs version |
System Info 💻
|
|
Can you explain how hour setup can install org package at all? You set |
|
Sorry. I just noticed that you are using add-to-list. So you are probably relying on default value of package-archive to already have elpa.gnu.org. |
|
@emacs18 I was referring to to the snippet from @lebensterben Otherwise I'm relying on the standard spacemacs layers dotspacemacs-configuration-layers
'(
(org :variables
org-enable-hugo-support t
org-enable-valign nil
)
) |
|
@RidaAyed Your snippet sets the value of the For clarity, on my machine, Spacemacs computes |
|
Nope there is nothing hindering users to use this workaround except that the issue may reappear each time the org package is updated :(. To be honest I do not see much we can do to work around this problem, in principle its a package.el bug which has been fixed there already, and will not appear in emacs 29.1 users should consider upgrading rather then doing all these workarounds in my humble opinion. |
Indeed. I'd say once Ubuntu and Fedora both ship 29.1 in the official repo, Spacemacs should no longer officially support ealier versions of Emacs. Perhaps we should consider advising users install Guix and then they'd get access to 29.1 immediately, rather than waiting for other distros to ship different builds of the same upstream tag of Emacs, we'd rely on one, reproducible build? |
|
@smile13241324 For now, could you pin this issue, Maxi?, if you're able? It's relevant enough that it should have more visibility. |
|
@bryce-carson, pinned. Yes indeed once 29.1 is officially released we should set the minimum version to 29.1 at least until there is an Ubuntu and Debian build available for it. |
|
Just chiming in, once/if we are able to find an automatic workaround for this issue, we should implement it. Otherwise, add a check in spacemacs to abort startup and show a message warning that the current version is less than 29.1 with a link to this issue. This way, it would prevent the bug from making spacemacs unusable until the user acknowledges the issue. I see this as a more useful fix than setting a minimum version, as it's going to be quite a while before 29.x is propagated to every distribution and every user updates. In the meantime, what happens when someone goes to open spacemacs after a while and it unexpectedly bricks itself? Dropping support for previous versions only introduces more support headaches, as people will continue to report this bug for as long as it occurs in the wild. We have access to elisp and version checks, and I think we should use them. This is an unfortunate situation that we shouldn't have to deal with, but let's make the most of it. I guess that I'm just opposed to focusing on popular distributions because I started using spacemacs on a chromebook in a free VM and all other cursed manner of setups. If we want the latest version to be a hard requirement, we need to direct new users on how to install it on any platform, even if that's just dropping a link to emacs' installation guide. |
The plan is to change the minimum supported version in Spacemacs itself, which after some minor refactoring, should refuse to initialize on ealier versions of Emacs. That's not a problem for any motivated user of an earlier Emacs version. Spacemacs is not currently bricked, and Spacemacs will not brick itself in any case. The problem is actually quite minor. Closed issues can remain pinned, and documentation, guides, and READMEs serve better the purpose of communicating known issues to users. The only real fix would be a labourious backport. The current work-around has a much lower development threshold; granted, a better and automatic solution would be preferred, but there are considerations to make. First, should we prevent users from updating Org automatically? If so, we can hold the package by specifiying a version string for it in (customize-set-variable 'package-load-list '(all (org "9.6.6")))The consideration then becomes, "What version?" We might leave this up to users to decide, simply providing them the instruction so they only need to perform the current work-around procedure once, hold the package, and then forget about the issue. An automated procedure is too delicate to spend our time on, I feel. Another solution is to prevent Org from loading at all by setting the cdr of the list containing the symbol There's multiple solutions, but I'm not sure which would be best. I think instructing users to hold the Org package at a desired version using the above form after following the current work-around procedure is easiest. |
|
@bryce-carson I agree with you. I'm thinking that refusing to load org may be the best option, as it preserves other functionality by quarantine, disabling org rather than trying to make spacemacs fix the issue. This way, people who don't use org are unaffected and if there's still demand for a fix, pre-29.1 users can work to explore other options. In my eyes, the main benefit of this solution is making spacemacs "just work" for people who don't understand the inner workings. |
|
As a follow-up, rather than editing, when Spacemacs drops support for a version of Emacs it only means that if the reported issue is caused by something in that version, such as the present issue, we probably won't make an effort to provide a work-around. This issue is unique because it's caused by package.el and interacts exotically with Org. Other packages aren't suffering this issue (yet). In the current supported versions of Emacs, 27.1 or 28.2, the question "Is it an issue with Org, or package.el? Which do we address?" can be asked. As I said in the previous comment, the fixes to package.el in 29.1 could be back-ported, which is labourious indeed. It's also fidddlesome, apart from the labour needed. It could introduce more issues. It might be easier to hold Org to the 9.5 series, especially for new installations, and if a user wishes to upgrade Org then the work-around and further package version hand-holding would be advised. |
|
Hmm... So keeping org at 9.5.x by default (if a version below 29.1 is detected) would work? If so, I agree, that's a better idea. Is it possible to limit this behavior to only pre-29.1 versions, so that new installs on 29.1 or above don't get stuck with an old org package? |
|
It's trivial, actually. We'd simply add the following to (when (version< emacs-version "29.1")
(customize-set-variable 'package-load-list '(all (org "9.5.5"))))I'm not sure how related to the present issue it is, the upstream package website formerly published its own ELPA archive for Org packages (see https://orgmode.org/elpa.html). Org 9.5 was the last package version to work with this (Org 9.5.5 is distributed from GNU ELPA directly), and Org ELPA itself might become deprecated and offlined in the future. While we wait... a year? for 29.1 to land in Ubuntu (Fedora will have it in 39 if Emacs 29.1 gets released ahead of schedule) we might find other issues caused by Org ELPA's past. With the "trivial" addition to early-init, we need to ask whether this will causes issues in sites with more recent versions of Org already installed, and how that will interact with byte compilation on 28.2, the portable dumper on 27.1, etc. Edit: clarified a clause.
|
Oh boy, I'm starting to see what you mean. In the meantime, applying that "trivial" fix to new installations seems safe, assuming spacemacs has a way of detecting that. |
Indeed. That's why communication is easier. Spacemacs does not have as many active hackers as Doom Emacs does, and even fewer contributors understand it all. The best way to ensure new installations include the change is to provide the code to users in the installation instructions. Feel free to submit a PR against the README if you want to get involved. Spacemacs needs more active contributors hacking on and proofing the documentation. |
|
Appreciate the response at all, I'll look at it when I'm done with my current work. |
Sounds good. I'm investigating the consequences of shipping the change by default (27.1 and such). |
The primary issue with Org is that it is a large package with multiple files and macros are actively used. The latter is a challenge for Emacs byte compilation. Void/invalid function issues were not rare reports on the Org mailing list, and it is a reason for the https://orgmode.org/worg/org-faq.html#mixed-install note. The idea of
Wouldn't it better to keep the built-in version of Org? |
Once |
That would be the purpose behind holding the package, to prefer the built-in package. On most platforms, that seems to be 9.5.5; for any platform that has a version less than 9.5, it's okay to uprade to 9.5.x, just not to 9.6. For systems where 9.5.5 is distributed, it keeps the built-in, otherwise we allow upgrade to the newer version that doesn't produce the error. That is only if we introduce this breaking change, however. |
|
I encountered the problem while upgrading Spacemacs and was able to resolve it by deleting the old org files. However, I encountered some errors initially, which were resolved after restarting Spacemacs. Although I accidentally resolved the problem, I am concerned that it may resurface later. Therefore, I believe it is necessary to investigate the issue related with the old org files in more detail. |
|
I've just bumped into this (ironically) after applying " Update htmlize \ Fix for the org version conflict." 6e5816b Rolling back my packages to their 2023.07.12 version solved the problem. |
|
I tried @lebensterben and other ways to fix this but no luck. org-version returns the new correct version 9.6.7 but still I get (invalid-function org-assert-version) |
It does not matter. I followed @lebensterben and also got the message, "‘org’ is already installed". I restart the emacs. The org model works fine. |
|
I did what said @lebensterben and worked until I restart spacemacs so I decided to install Emacs 29 because of someone here said that there was not problem and now it works. |
|
In addition to installing Emacs 29.1, I had to put the following into |
smile13241324
changed the title
org-mode is broken after restarting emacs on latest developorg-mode is broken after restarting emacs on latest develop when emacs < 29
|
Workaround in emacs 29.3: After nothing else worked (I tried many of the suggestions here, but I am not using Potentially I first removed org with Problems: I discovered some issues with cycling (it would sometimes close outer trees) and inserting new subtrees (sometimes inserting at random other places) but I am not sure whether this is due to the new version (and interaction with other packages) or both org versions being loaded as others mentioned in this thread (I am not loading anything org-specific in
Regarding updating: When there is an update for the Are there any other experiences with this issue for emacs 29.3? |
and others
Description
org-modeis broken. Opening an org file doesn't load theorg-mode.I tried removing all org packages, restart emacs to let it install all the packages and then open an org file which works for that session. If you quit and restart it throws
(invalid-function org-assert-version)error.Reproduction guide 🪲
org-9.6.1andorg-contrib-0.4.1from~/.emacs.d/elpa/28.2/develop.Observed behaviour: 👀 💔
Opening an org file throws following error.
Expected behaviour: ❤️ 😄
Opens file and applies org-mode and related layer configuration.
System Info 💻
The text was updated successfully, but these errors were encountered: