‘org-element-at-point’ cannot be used in non-Org buffer

[tkossak]

Reposting syl20bnr/spacemacs#16575 since it seems to be an issue with helm-org.

When I press SPC j i (command spacemacs/helm-jump-in-buffer) I get multiple errors:
⛔ Warning (org-element): ‘org-element-at-point’ cannot be used in non-Org buffer #<buffer *helm org inbuffer*> (helm-major-mode)

Reproduction

1. Install spacemacs from scratch

mv ~/.emacs.d ~/.emacs.d.old
mv ~/.spacemacs ~/.spacemacs.old

git clone --recursive https://github.com/syl20bnr/spacemacs ~/.emacs.d

2. Create dotfile as ~/.spacemacs. Only few lines changed from default dotfile - I added org layer, removed multi cursor layer and added these 2 lines:

   (setq helm-org-format-outline-path nil)
   (setq org-startup-indented 't)
   

3. Create sample org file eg test.org with content:

   * heading1
   blabla
   

4. Start spacemacs and perform first time installation of all packages it asks for

5. Open test.org and press SPC j i. Result:
   

[fnussbaum]

FWIW in Spacemacs SPC j i in an Org buffer calls helm-org-in-buffer-headings. The warnings seems to come from helm-org-indent-headings-1 enabling org-indent-mode in the Helm buffer.

[thierryvolpiatto]

Kossak ***@***.***> writes:

1. ( ) text/plain (*) text/html Reposting syl20bnr/spacemacs#16575 since it seems to be an issue with helm-org. When I press SPC j i (command spacemacs/helm-jump-in-buffer) I get multiple errors: ⛔ Warning (org-element): ‘org-element-at-point’ cannot be used in non-Org buffer #<buffer *helm org inbuffer*> (helm-major-mode)

Sorry I am not aware of the spacemacs* commands.

Reproduction 1. Install spacemacs from scratch

I do not use Spacemacs (and will not install it). Please use a minimal config starting from emacs -Q or use the script emacs-helm.sh to reproduce your bug. If your packages are installed from package.el, you can also use the isolate package action from M-x helm-packages. Thanks.

…

-- Thierry

[thierryvolpiatto]

fnussbaum ***@***.***> writes:

FWIW in Spacemacs SPC j i in an Org buffer calls helm-org-in-buffer-headings. The warnings seems to come from helm-org-indent-headings-1 enabling org-indent-mode in the Helm buffer.

But AFAICT org-indent-mode is not calling org-element-at-point, at least on the versions of org used by emacs-29.4 and emacs-31+. So what is calling org-element-at-point?

…

— Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you are subscribed to this thread.*Message ID: ***@***.***>

-- Thierry

[fnussbaum]

So what is calling org-element-at-point?

I got the following backtrace on my system with Org 9.7.11:

Debugger entered--entering a function:
* org-element-at-point()
  org-at-item-p()
  org-indent-add-properties(1 24)
  org-indent-refresh-maybe(1 24 0)
  helm-insert-header("Org headings (test.org)" nil)
  helm-insert-header-from-source(...)
  helm-render-source(...)
  helm-update("\\* test")
  helm-read-from-minibuffer(nil nil "\\* test" nil nil nil nil)
  helm-internal(...)
  helm(...)
  helm(...)
  helm-org-in-buffer-headings(nil)
  funcall-interactively(helm-org-in-buffer-headings nil)
  call-interactively(helm-org-in-buffer-headings)

Reproduction steps from ./emacs-helm.sh --load-packages org,helm-org, in particular with org-version 9.7.11:

Evaluate

(progn 
  (setq org-startup-indented t)
  (setq helm-org-format-outline-path nil))

Create a buffer test.org with the following content:

* test
test

Optionally evaluate

(add-hook
 'org-indent-mode-hook
 (defun debug-on-org-element-at-point ()
   (debug-on-entry #'org-element-at-point)))

Execute M-x helm-org-in-buffer-headings. This should reproduce the warnings (or enter the debugger).

[thierryvolpiatto]

fnussbaum ***@***.***> writes:

So what is calling org-element-at-point? I got the following backtrace on my system with Org 9.7.11: Debugger entered--entering a function: * org-element-at-point() org-at-item-p() org-indent-add-properties(1 24) org-indent-refresh-maybe(1 24 0) helm-insert-header("Org headings (test.org)" nil) helm-insert-header-from-source(...) helm-render-source(...) helm-update("\\* test") helm-read-from-minibuffer(nil nil "\\* test" nil nil nil nil) helm-internal(...) helm(...) helm(...) helm-org-in-buffer-headings(nil) funcall-interactively(helm-org-in-buffer-headings nil) call-interactively(helm-org-in-buffer-headings) Reproduction steps from ./emacs-helm.sh --load-packages org,helm-org, in particular with org-version 9.7.11: Evaluate (progn (setq org-startup-indented t) (setq helm-org-format-outline-path nil)) Create a buffer test.org with the following content: * test test Optionally evaluate (add-hook 'org-indent-mode-hook (defun debug-on-org-element-at-point () (debug-on-entry #'org-element-at-point))) Execute M-x helm-org-in-buffer-headings. This should reproduce the warnings (or enter the debugger).

Thanks for the recipe. I fixed it by adding (setq-local warning-suppress-log-types '((org-element))) in helm-buffer, however I guess it should be reported as an emacs-bug, there is no reason to limit this code to org-mode buffers (emacs-29 was not doing this).

…

— Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you commented.*Message ID: ***@***.***>

-- Thierry

[fnussbaum]

Thanks, I agree that in this case of helm-org, it is likely completely safe to ignore the warning.

In general, org-element-at-point can apparently cause random errors in non-org buffers, and the Org developers do not seem to intend to support every such use case, see for example https://list.orgmode.org/874jeuont7.fsf@localhost/. Hence I do not think that this needs to be reported upstream.

[alphapapa]

there is no reason to limit this code to org-mode buffers (emacs-29 was not doing this).

AFAIU that is (unfortunately for downstream developers) no longer the case, hence the new warning. I've had to apply fixes for this in some of my own projects.

AFAIK one should generally not call org functions in non-Org buffers unless one knows it will work, including the whole chain of functions that such a call entails. (This may not have been the case in the past, but as Org is trying to become more modular and well-organized, it's probably a good rule of thumb now.)

[thierryvolpiatto]

Hello Adam, Adam Porter ***@***.***> writes:

there is no reason to limit this code to org-mode buffers (emacs-29 was not doing this). AFAIU that is (unfortunately for downstream developers) no longer the case, hence the new warning. I've had to apply fixes for this in some of my own projects.

Out of curiosity, how did you fix this? Thanks.

…

-- Thierry

[thierryvolpiatto]

fnussbaum ***@***.***> writes:

Thanks, I agree that in this case of helm-org, it is likely completely safe to ignore the warning. In general, org-element-at-point can apparently cause random errors in non-org buffers, and the Org developers do not seem to intend to support every such use case, see for example ***@***.***/. Hence I do not think that this needs to be reported upstream.

Ok I see, so it is a known problem. Thanks both for help on this.

…

— Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you commented.*Message ID: ***@***.***>

-- Thierry

[alphapapa]

Hi Thierry,

Out of curiosity, how did you fix this? Thanks.

AFAIR you should either avoid using the function or make sure the buffer is in org-mode. There might be some exceptions in which you can get away with it, but there's no promise that they'll continue to work that way in the future, so it's probably not a good idea.

[thierryvolpiatto]

Adam Porter ***@***.***> writes:

1. ( ) text/plain (*) text/html Hi Thierry, Out of curiosity, how did you fix this? Thanks. AFAIR you should either avoid using the function or make sure the buffer is in org-mode. There might be some exceptions in which you can get away with it, but there's no promise that they'll continue to work that way in the future, so it's probably not a good idea.

Ok, thanks.

…

— Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you commented.*Message ID: ***@***.***>

-- Thierry