oantolin
`(wrong-type-argument number-or-marker-p nil)` when "clicking" Org mode link with `embark-act`
Hi!
When I click a link in Org mode with embark-act, I get the following backtrace:
Debugger entered--Lisp error: (wrong-type-argument number-or-marker-p nil)
embark-org-target-element-context()
#f(compiled-function (fun) #<bytecode 0x551bde5be1cc115>)(embark-org-target-element-context)
embark--targets()
embark-act(nil)
funcall-interactively(embark-act nil)
command-execute(embark-act)
This error only has shown up recently, but of course it may be due to my specific setup. Let me know if I can provide more details or should try with emacs- Q.
Same here with emacs -Q.
I guess new org version 9.7 has some changes related to org element.
Its weird. yantar on matrix confirmed that its not happending.
So I eval the embark-org buffer, and it worked as expected.
Not sure what is causing this. Yantar pointed out something to do with native comp, so as I use nix to manage emacs packages, update or recompiling may solve it.
That's right! When I evaluate the embark-org buffer, it starts working.
However, and this is weird: When I evaluate
(with-eval-after-load 'org
(require 'embark-org))
which is the last bit of embark.org, it still does NOT work. I guess this is because it loads the byte compiled file.
So I went ahead, and byte-compiled embark-org.el, and lo and behold the byte compiled files differ. I have no idea how to diff them or what's the reason for the difference... I am also using Nix, so should we report this upstream?
I'm sorry, I don't think I understand what could cause this other than it seems like maybe it's some sort of installation problem? After installing Org 9.7, I reinstalled every package with an org dependency, just in case and have had no problems.
To be honest, I suspect this being a problem within Nix. For example, it could be that the Emacs used to byte-compile the file is not yet using Org mode 9.7? I will poke around further.
@idlip which update are you referring to? I am still observing this problem, but I think it is unrelated to embark. It seems to be Nix-specific.
I meant to say, with emacs overlay update and its pakcages on yesterday with org 9.7.5 there is no issue for me.
On Tue, Jun 25, 2024, 12:39 AM Dominik Schrempf @.***> wrote:
@idlip https://github.com/idlip which update are you referring to? I am still observing this problem, but I think it is unrelated to embark. It seems to be Nix-specific.
— Reply to this email directly, view it on GitHub https://github.com/oantolin/embark/issues/723#issuecomment-2187229270, or unsubscribe https://github.com/notifications/unsubscribe-auth/A34ZJ7LSA7SNVCJM7CA3ZNDZJBVHDAVCNFSM6AAAAABJAGE2HGVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDCOBXGIZDSMRXGA . You are receiving this because you were mentioned.Message ID: @.***>
I was getting this error with Guix packages. Debugging the byte-compiled embark-org-target-element-context, it becomes clear that it was compiled with an org-element-property that is a defsubst calling plist-get, which was the case in Org 9.6. But in Org 9.7, org-element-property becomes more complex. :begin is moved into an array of “standard properties”, presumably for performance reasons. This causes the naïve plist-get to fail when operating on values returned from org-element-lineage from Org 9.7 (which you presumably have installed via Nix).
Like Guix, I suspect this mismatch is because the Nix package for Embark doesn’t list the standalone Org package as an input, so compilation of embark-org is done with the Org shipped with Emacs 29, so embark-org-target-element-context ends up calling plist-get instead of the more substantial Org 9.7 org-element-property.
I fixed it by overriding my Embark package to include Org 9.7 as an input. Presumably you could do similarly in an overlay.
This is a clash between Guix/Nix’s attempts at hermetic builds and Emacs shipping with a bunch of packages that people like to upgrade to the lastest standalone versions. We could add the newer, standalone Org package as a propagated input for any dependents like Embark, but some Embark users might not use Org. So maybe Guix/Nix should package embark-org separately and declare the propagated input there. But maybe some users prefer to stick with the Org version embedded in Emacs? So it’s tough. Definitely a packaging concern rather than an Embark issue, though.
Not sure if this is a good idea, but in my case, I was able to work around the issue by doing:
(setq
embark-target-finders
(remove 'embark-org-target-element-context embark-target-finders))
ps: I'm using emacs("29.4"), embark(1.1), and org(9.6.15; built-in)
Well, that just removes most of embark's org support, @rmathew8-gh. I'd suggest instead loading org and recompiling embark-org.
@oantolin I'm using straight, and I don't see embark-org as a separate package. It does show in the list of features. I did a (straight-rebuild-package "embark") without any luck. Even with a minimal .emacs with just org and embark, I still can't seem to get embark-act to work on org links. If you have any diagnostic suggestions, happy to try them out
Well, I already suggested it but I can suggest the same thing again: find your copy of embark-org and recompile it. More specifically, first load org with M-x load-library RET org RET, then do M-x find-library RET embark-org RET and finally M-x elisp-byte-compile-file. Please let me know if that works. I cannot reproduce this problem, so I suspect it is something straight.el does. I unfortunately cannot support non-standard installation methods.
@oantolin I byte-compiled all files, restarted emacs, but same issue. fwiw, here's the listing
/home/roy/.emacs.d/straight/repos/embark:
drwxr-xr-x 3 roy roy 4096 Feb 23 22:04 .
-rw-r--r-- 1 roy roy 144 Feb 23 22:04 .gitignore.elc
-rw-r--r-- 1 roy roy 27462 Feb 23 22:04 embark-org.elc
-rw-r--r-- 1 roy roy 163718 Feb 23 22:04 embark.elc
-rw-r--r-- 1 roy roy 15235 Feb 23 22:04 embark-consult.elc
-rw-r--r-- 1 roy roy 87 Feb 23 22:04 .elpaignore.elc
-rw-r--r-- 1 roy roy 158 Feb 23 22:04 .dir-locals.elc
drwxr-xr-x 7 roy roy 4096 Feb 23 22:03 .git
drwxr-xr-x 109 roy roy 4096 Feb 12 10:07 ..
-rw-r--r-- 1 roy roy 19657 Feb 5 07:28 embark-consult.el
-rw-r--r-- 1 roy roy 3390 Jan 27 13:10 avy-embark-collect.el
-rw-r--r-- 1 roy roy 191323 Jan 27 13:10 embark.el
-rw-r--r-- 1 roy roy 26769 Jan 27 13:10 embark-org.el
-rw-r--r-- 1 roy roy 68992 Jan 27 13:10 embark.texi
-rw-r--r-- 1 roy roy 35149 Jan 27 13:10 LICENSE
-rw-r--r-- 1 roy roy 63156 Jan 27 13:10 README.org
-rw-r--r-- 1 roy roy 5627 Jan 27 13:10 CHANGELOG.org
-rw-r--r-- 1 roy roy 177 Jan 27 13:10 .dir-locals.el
-rw-r--r-- 1 roy roy 7 Jan 27 13:10 .elpaignore
-rw-r--r-- 1 roy roy 30 Jan 27 13:10 .gitignore
I'm using commit d5df0eff182b014ab49328a4dbb1d69eb7faafbd
I also get this (not with emacs -Q). When I edebug-instrument embark-org-target-element-context, everything seems to work fine afterwards 😱
Which allows for this super-hacky workaround:
;; try to work-around https://github.com/oantolin/embark/issues/723
(with-eval-after-load 'embark-org
(let* ((definition (find-definition-noselect #'embark-org-target-element-context nil))
(buf (car definition))
(position (cdr-safe definition)))
(if position
(with-current-buffer buf
(save-excursion
(goto-char position)
(edebug-defun))
(edebug-remove-instrumentation '(embark-org-target-element-context)))
(warn "Definition of `embark-org-target-element-context' not found in `embark-org'"))))
Can you reproduce the problem from
emacs -Q?
Hmm.. just switched to emacs-30 and the issue seems to be fixed!