search

oantolin / embark

Emacs Mini-Buffer Actions Rooted in Keymaps
GNU General Public License v3.0
941 stars 56 forks source link

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

Open dschrempf opened 5 months ago

dschrempf commented 5 months ago

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 commented 5 months ago

Same here with emacs -Q.

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

idlip commented 5 months ago

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 commented 5 months ago

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 commented 5 months ago

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 commented 5 months ago

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 commented 4 months ago

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

dschrempf commented 4 months ago

@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 commented 4 months ago

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

dschrempf commented 4 months ago

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

hpfr commented 4 months ago

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.