(wrong-type-argument number-or-marker-p nil) when "clicking" Org mode link with embark-act

[dschrempf]

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.

[idlip]

Same here with emacs -Q.

I guess new org version 9.7 has some changes related to org element.

[idlip]

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.

[dschrempf]

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?

[oantolin]

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.

[dschrempf]

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]

Hey @dschrempf , there is no issue with recent update.

[dschrempf]

@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.

[idlip]

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 <#723 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/A34ZJ7LSA7SNVCJM7CA3ZNDZJBVHDAVCNFSM6AAAAABJAGE2HGVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDCOBXGIZDSMRXGA> . You are receiving this because you were mentioned.Message ID: ***@***.***>

[dschrempf]

Hm, I am still observing this, even after updating emacs-overlay.

[hpfr]

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.