org-ql-find has no visible effect

OS/platform

Windows 10

Emacs version and provenance

Emacs 28.2.50 compiled with MSYS2 MinGW

Emacs command

runemacs.exe

Org version and provenance

9.6.18 installed via Spacemacs org layer

org-ql package version and provenance

20240113.647 via Spacemacs github fetcher

Actions taken

Opened an org-mode buffer
M-x org-ql-find

Observed results

Nothing happens

Expected results

Prompt with "Find entry: "

Backtrace

No error was signaled

Etc.

I edebugged the relevant functions and the edebug session ends on

https://github.com/alphapapa/org-ql/blob/master/org-ql-completing-read.el#L345

With this in the *Messages* buffer: (closure (t) nil "Show org-ql-view' buffer for current org-ql-comp..." (interactive) (user-error "Not in an `org-ql-completing-read' session"))

You're running an old, unreleased version of Emacs, compiled in a possibly non-standard way, with Spacemacs as a middleman, and you're getting an error message from a different function that can only be called by user action. I can only guess that it's a problem with the installation, with Spacemacs, or with your own configuration, because it works fine in a clean Emacs configuration when installed properly; you can verify this yourself using, e.g. https://github.com/alphapapa/with-emacs.sh

Thanks for taking a look! Fair points. The background for this version of Emacs is that it was the only one that I could get to run reliably on Windows at that time and that met my requirements (e.g. dynamic module loading).

I am painfully aware that it is very hard to reproduce Emacs issues due to all possible variations and additional layers such as Spacemacs - and thus how hard it is for you to give support and diagnose.

Do you have any idea how I could debug this further as I am not getting anything back from the org-ql-find that would be actionable for further debugging (even with toggle-debug-on-error). And as mentioned, even in an edebug session, I am unable to zone in on the root cause, hence my issue here that should have been a question.

Well, if you really want to keep using Spacemacs, then I'd suggest something like:

Installing org-ql outside of Spacemacs's machinery. Use package-install and install it from MELPA, which should install it correctly (which Spacemacs might not be doing).
If that doesn't help, then I'd suggest avoiding use of the entire Org layer in Spacemacs, and install both Org and org-ql outside of Spacemacs's machinery.

It seems likely that something hasn't been installed or compiled correctly, so that might help.

If neither of those help, then I'd guess that something else in Spacemacs is causing it. (I've nothing against Spacemacs; I tried it a few times, and it's nice. But I can only guess that a problem as bizarre as this is caused by something it does.) So I'd suggest trying to reproduce the problem in a clean Emacs configuration. If you can't, then you will have nearly confirmed that it's due to Spacemacs, so you could then ask Spacemacs folks for help.

Other than that, debugging issues with functions that call completing-read and the like can be difficult. Since the error message comes from org-ql-completing-read-export, you should probably try to figure out what is calling that function. You can see in the source code that it's bound in a keymap and that embark-export is temporarily rebound to it as well.

Thanks for the details and suggestions!

Since the error message comes from org-ql-completing-read-export, you should probably try to figure out what is calling that function.

This is the part I am most confused about. As mentioned in OP under "Etc." org-ql-completing-read-export does not even get called, it fails after "letf-binding" it to symbol-function. The debug session just stops after printing the function closure.

Edit: Sometimes while stepping in edebug I get to the point where a *helm-mode-org-ql-find* buffer opens, I can then enter a character after which I am back in the edebug session, again on

org-ql/org-ql-completing-read.el

Line 345 in 8d3c93b

(cl-letf* (((symbol-function 'org-ql-completing-read-export)

and if I then edebug step once more, the edebug session ends without an error or any other feedback.

I will try to figure out if this behavior changes when I change Spacemacs completion config.

I was close to it a few times already and took this opportunity to finally declare helm bankrupcty. The related ad-hoc helm configuration debts considerably compounded over the years.

tl;dr: I changed from helm to vertico/consult/embark/marginalia/orderless and the issue went away.

Ok, so I think the problem was that you had helm-mode enabled (not that you had Helm installed), and helm-mode takes over completing-read (which it is intended to do), which interferes with org-ql-find--which is mentioned in an issue somewhere on this tracker.

That's why there's a separate package for Helm support, helm-org-ql. So you could have just used that. :)

I could have used helm-org-ql, but would then have hit #275 again :) Thanks for mentioning anyways, but I feel my time with helm is finally over.

Hm, still need a more dedicated Helm user to file a report about that bug upstream.