Hidden parent headings when using helm-org-rifle-current-buffer on collapsed hierarchies

[novoid]

I'm sorry when the subject doesn't cover the thing I want to address. Hence a more verbose explanation of my issue at hand:

I'm in a large Org file and using helm-org-rifle-current-buffer in order to find a particular heading in my (partly) collapsed hierarchy.

Simplified example:

* one
  * two
    * three
      * 2024-06-12 heading
    * foo
  * bar
  * baz

When invoked a search for 2024-06-12 with the headings below "two" in a collapsed state, I end up with a view like:

* one
  * two
      * 2024-06-12 heading

... where I can't access "three" or its direct neighbours that easily. In other words, some but not all parent headings are visible.

According to my tests, even "two" is not shown when it was hidden before I invoked the rifle command. The general rule seems to be: "show the matching heading but don't show collapsed parent headings".

Is there some kind of option I might activate so that I always see all parent headings when accessing a search result heading?

When I'm using org-occur does reveal all the parent headings even when they were collapsed.

Thanks for any pointer

Org-mode 9.6.28 on Emacs 29.3 (NixOS), helm-org-rifle 20230821.1927

[alphapapa]

Hi Karl,

You should be able to use the option helm-org-rifle-show-entry-function to handle this in the desired way. (There are too many possibilities to account for, so just providing a function to do the job is the best way.)

BTW, while I do intend for org-rifle to remain usable, I generally recommend using org-ql instead; e.g. org-ql-find should generally do the same job well, even if not identically.

[yantar92]

FYI, during the discussion in OrgMeetup, we have found that there is one important feature of helm-org-rifle that is missing in org-ql - displaying exact line matching search string inside the heading. org-ql cannot do it - it only displays the outline path.

[alphapapa]

displaying exact line matching search string inside the heading. org-ql cannot do it

It can do it. See option org-ql-completing-read-snippet-function. If you set it to: org-ql-completing-read--snippet-regexp ("Return a snippet of the current entry’s matches for REGEXP."), it does essentially the same thing. However, inside the completing-read interface, it seems to perform poorly, so I haven't enabled it by default.

I don't know why it doesn't perform as well. It might be something to do with using the completing-read API that Helm does differently, or it might be something else. I spent hours trying to solve it, but it's very hard to profile and troubleshoot things that run within completing-read.

[yantar92]

org-ql-completing-read--snippet-regexp

Hmm... We mostly looked at helm-org-ql :)

I don't know why it doesn't perform as well. It might be something to do with using the completing-read API that Helm does differently, or it might be something else. I spent hours trying to solve it, but it's very hard to profile and troubleshoot things that run within completing-read.

My usual suspect with completing read is the fact that it is not limiting the number of matches. So, things might get quite slow when the completion lists is long (short query).

[alphapapa]

org-ql-completing-read--snippet-regexp

Hmm... We mostly looked at helm-org-ql :)

Ah, you didn't mention that. It does not use the same options as org-ql-find, and I haven't touched that package in quite a while. AFAIK it works, but my effort goes into org-ql-find now.

I don't know why it doesn't perform as well. It might be something to do with using the completing-read API that Helm does differently, or it might be something else. I spent hours trying to solve it, but it's very hard to profile and troubleshoot things that run within completing-read.

My usual suspect with completing read is the fact that it is not limiting the number of matches. So, things might get quite slow when the completion lists is long (short query).

The snippets are added via an annotation function, which (should) only be run on candidates which are to be displayed (i.e. in Vertico with Marginalia), not all of them.

[yantar92]

The snippets are added via an annotation function, which (should) only be run on candidates which are to be displayed (i.e. in Vertico with Marginalia), not all of them.

If they work via completion API, it is probably not true - completion API works via completions buffer that lists all the possible completions (you can literally switch to that buffer and see that it annotates every single completion out there)

[yantar92]

P.S. You can try M-x elp-instrument-function + M-x elp-results to check the number of calls to a given function.

[alphapapa]

FWIW, there's currently a small bug in org-ql-completing-read.el regarding the snippet feature; with that corrected, it works like this (showing Vertico and Marginalia):

If they work via completion API, it is probably not true - completion API works via completions buffer that lists all the possible completions (you can literally switch to that buffer and see that it annotates every single completion out there)

Well, I thought the whole point of the annotation/affixation API features was to not annotate every candidate, but only ones that are to be displayed at the moment--otherwise one might as well make every candidate string itself pre-annotated. I don't have time to investigate further right now, but if you are correct, that would seem strange to me.