consult-org-heading preview

[gusbrs]

consult-org-heading's previews will show the current candidate in the buffer "as is", if the candidate happens to be visible. However, if the candidate is invisible, the preview completely unfolds it, showing full contents of the headings around, including drawers, etc. So, the more hidden something is at the start of completion, the more it is shown on preview.

I think it would be more consistent if consult-org-heading was less aggressive in unfolding candidates, and only showed sibling headings instead.

To demonstrate the mentioned effect, start with emacs -Q, do a minimal setup:

(add-to-list 'load-path "~/.emacs.d/elpa/vertico-1.0.0.20230122.111702")
(add-to-list 'load-path "~/.emacs.d/elpa/consult-0.31.0.20230122.155417")
(add-to-list 'load-path "~/.emacs.d/elpa/compat-29.1.3.0")
(require 'vertico)
(require 'consult)
(require 'org)
(require 'consult-org)
(vertico-mode)

Visit an .org file with contents:

#+title: consult-org-heading preview test

* Heading 1

** Heading 1.1
:PROPERTIES:
:prop_1: foo
:prop_1: bar
:END:

Lorem ipsum

** Heading 1.2
:PROPERTIES:
:prop_1: foo
:prop_1: bar
:END:

Lorem ipsum

** Heading 1.3
:PROPERTIES:
:prop_1: foo
:prop_1: bar
:END:

Lorem ipsum

* Heading 2
:PROPERTIES:
:VISIBILITY: folded
:END:

** Heading 2.1
:PROPERTIES:
:prop_1: foo
:prop_1: bar
:END:

Lorem ipsum

** Heading 2.2
:PROPERTIES:
:prop_1: foo
:prop_1: bar
:END:

Lorem ipsum

** Heading 2.3
:PROPERTIES:
:prop_1: foo
:prop_1: bar
:END:

Lorem ipsum

* Heading 3

** Heading 3.1
:PROPERTIES:
:prop_1: foo
:prop_1: bar
:END:

Lorem ipsum

** Heading 3.2
:PROPERTIES:
:prop_1: foo
:prop_1: bar
:END:

Lorem ipsum

** Heading 3.3
:PROPERTIES:
:prop_1: foo
:prop_1: bar
:END:

Lorem ipsum

#+STARTUP: content

The file will open as:

Call consult-org-heading, and navigate candidate by candidate using C-n. While on "Heading 1" and its subheadings, the preview does not show anything else other than the folded headings. But, when "Heading 2.1" is reached, now we get:

I'm not sure if this behavior is due to technical limitations, or if this is related to the new org-fold library (which I don't yet have here), as discussed in #563. But, if the "unfold only sibling headings" behavior is possible, I think it would be desirable, and an improvement over the current one.

The point above is general but, for context, I got concerned with this because I use an .org.gpg file as my password manager, with a derived major mode provided by a personal library akin to org-passwords.el, where I disable the usual stuff, like not letting search-invisible be 'open etc. But regardless of that, consult-org-heading is quite indiscreet. For the time being, I set consult-preview-key locally to nil. This works because it is a personal library, but if it wasn't, it would still not be a safe way to disable it, since it can always be overridden by consult-customize. But I diverge, the point here is just a suggestion of better unfolding behavior for the previews.

(Running GNU Emacs 28.2 (build 2, x86_64-pc-linux-gnu, GTK+ Version 3.24.20, cairo version 1.16.0) of 2022-09-12, Org mode version 9.5.5 (release_9.5.5 @ /usr/local/share/emacs/28.2/lisp/org/) and the packages' versions loaded above).

[minad]

Yes, this ist due to technical limitations of the overlay unfolding API. The new org-fold API is not an improvement but rather a complication. Also org-fold is a bit buggy. Feel free to experiment with the API, see consult--invisible-open-temporarily. We could consider making it configurable, but I am actually happy with the status quo.

Regarding your password use case I recommend to use a netrc auth file instead. It provides a mode which hides passwords (via overlays). You could also develop a similar mode for Org.

[gusbrs]

Yes, this ist due to technical limitations of the overlay unfolding API. The new org-fold API is not an improvement but rather a complication. Also org-fold is a bit buggy. Feel free to experiment with the API, see consult--invisible-open-temporarily. We could consider making it configurable, but I am actually happy with the status quo.

I feared as much... But, well, I had to ask. Anyway, thanks for considering and answering.

Regarding your password use case I recommend to use a netrc auth file instead. It provides a mode which hides passwords (via overlays). You could also develop a similar mode for Org.

I'll take a look at it. Thanks for the suggestion.

Edit: For the record, the feature is implemented by 'authinfo-mode, and is straightforward to use inside an Org buffer. Just set an appropriate authinfo-hidden regexp, and call (authinfo--hide-passwords (point-min) (point-max)). But the feature relies on reveal-mode to show the password at point. It is fine in a regular netrc/auth file, but in an Org one, where a lot of things are invisible, there's a trade-off, since anything else but the password gets revealed as point moves around. Of course, with some more work, the technique can be adjusted not to rely on reveal-mode. But, in this case, to get auto-unhiding of the password at point, this "some more work" may be quite a lot. Still a good and appreciated tip!

[minad]

Iirc you can also configure this on the level of Org. There is a configuration variable (I don't remember the name) which sets how much should be unfolded for certain Org operations. Consult behaves like Isearch from the perspective of Org.

[gusbrs]

Iirc you can also configure this on the level of Org. There is a configuration variable (I don't remember the name) which sets how much should be unfolded for certain Org operations. Consult behaves like Isearch from the perspective of Org.

Is that org-show-context-detail? I had forgotten about it, but it turns out I have a note about that variable in my init with "I don't usually have to change its defaults, but it is an important option to keep in mind, so I leave a reference here." It appears the time has come. :-) Thanks for reminding me.

Edit: At least for Org 9.5.5, which is what I have here, consult-org-heading does not seem to honor org-show-context-detail but, given consult--invisible-open-temporarily, this may change with 9.6, I'll test it again when it comes.

[gusbrs]

@minad I'm not sure this is something you want to, or should for that matter, worry about, but for the record. You've recommended me above the password hiding technique of authinfo-mode to hide passwords and avoid live previews from disclosing information I'd not want it to. I'm doing this now and, while the previews indeed honor the display property used by it, candidates in the minibuffer don't.

So we get something like:

Again, sounds like I'm getting what I asked for. But I still thought it worth to bring to your consideration.

[minad]

@GusBR Yes, this is expected.

[minad]

I just had an idea - I think you should implement a vertico-censor-mode which modifies vertico--format-candidate and hides via predicates or regexps. I would say that this is the right solution for the problem. The other alternative would be to modify the candidates directly but this seems more ad-hoc, see consult--line-candidates.

[gusbrs]

I just had an idea - I think you should implement a vertico-censor-mode which modifies vertico--format-candidate and hides via predicates or regexps. I would say that this is the right solution for the problem.

That's an interesting idea, sounds promising. I'll play with it. Thanks!