8000 `(wrong-type-argument number-or-marker-p nil)` when "clicking" Org mode link with `embark-act` · Issue #723 · oantolin/embark · GitHub
[go: up one dir, main page]
More Web Proxy on the site http://driver.im/
Skip to content

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

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom
Open
8000
dschrempf opened this issue Jun 8, 2024 · 20 comments
Open

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

dschrempf opened this issue Jun 8, 2024 · 20 comments

Comments

@dschrempf
Copy link

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
Copy link
idlip commented Jun 10, 2024

Same here with emacs -Q.

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

@idlip
Copy link
idlip commented Jun 11, 2024

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
Copy link
Author

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
Copy link
Owner

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
Copy link
Author

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
Copy link
idlip commented Jun 24, 2024

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

@dschrempf
Copy link
Author

@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
Copy link
idlip commented Jun 25, 2024 via email

@dschrempf
Copy link
Author
dschrempf commented Jun 25, 2024 •
edited
Loading

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

@dschrempf dschrempf mentioned this issue Jul 2, 2024
Closed
@hpfr
Copy link
hpfr commented Jul 8, 2024

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.

@rmathew8-gh
Copy link
rmathew8-gh commented Feb 17, 2025 •
edited
Loading

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)

@oantolin
Copy link
Owner

Well, that just removes most of embark's org support, @rmathew8-gh. I'd suggest instead loading org and recompiling embark-org.

@rmathew8-gh
Copy link
rmathew8-gh commented Feb 18, 2025 •
edited
Loading

@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

@oantolin
Copy link
Owner
oantolin commented Feb 23, 2025 •
edited
Loading

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.

@rmathew8-gh
Copy link

@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

@oantolin
Copy link
Owner

Can you reproduce the problem from emacs -Q?

@hrehfeld
Copy link

I also get this (not with emacs -Q). When I edebug-instrument embark-org-target-element-context, everything seems to work fine afterwards 😱

@hrehfeld
Copy link
hrehfeld commented Feb 28, 2025 •
edited
Loading

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'"))))

@rmathew8-gh
Copy link

Can you reproduce the problem from emacs -Q?

Hmm.. just switched to emacs-30 and the issue seems to be fixed!

@oantolin
Copy link
Owner
oantolin commented Mar 4, 2025

That's good news! But very mysterious...

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
6 participants
@hrehfeld @oantolin @dschrempf @hpfr @idlip @rmathew8-gh
0