Group annotations

[jdtsmith]

In grep-like consult commands, the file name group headings usually leaves significant horizontal space. I wonder if it would be possible to implement an optional "group annotation function" which could (on demand) add a small annotation to this file heading. E.g., modification time (using our new seconds-to-string short form, naturally):

---------- [2d3h] ~/.emacs.d/init.el ----------------------------------------

The group annotations could ideally have their own faces.

[minad]

I must admit I don't really see the benefit of adding this, or more noise to the completion view. Maybe you have a bunch of more convincing examples than the modification time? This feature will add some complexity so it needs some good justification.

[minad]

Yes, I see some value there. But for this we'd first need a better solution for the options (#1283). Also only adding this for grep seems over the top. Do you see other use cases, e.g., with consult-multi?

We could try to extend the group function protocol, the CANDIDATE argument could be the title, the TRANSFORM argument could be 'annotation (or 'title) in order to only transform the title for display. Unfortunately this won't be backward compatible with existing group functions. Or maybe add a separate argument and then handle old group functions by catching argument errors. This would be backward compatible, but ugly.

An alternative would be to introduce a separate group-annotation-function, but at this point, the added complexity is hardly worth it.

[jdtsmith]

Agree on options. I find I do a lot of -- -some -narrowing -options -without-which -expensive! (where the leading space is important otherwise -- is seen as the search string), then C-a, but that puts me prior to the # punctuation leader, so move forward, then type my search string.

I had imagined a new :annotate-group keyword argument to consult--read but it seems that may not be the right place. One consideration is you don't want to request metadata on a file over and over. Just as the file group (for grep-ish) is cached in a candidate property, maybe group annotation could be too?

[minad]

The problem is that the group function must be very fast since it is used during grouping/sorting on all candidates. So if we reuse it to augment the title with additional information, we would need aggressive caching. My idea was to fetch the annotation only for the visible group titles from the UI, but this needs many more modifications (new metadata function, changes in Vertico and other UIs and so on).

[jdtsmith]

For the file flavor, if annotation is computed as soon as the file is seen and stored on the candidate as another text property, the same caching as is used to save memory would apply. Then the group function could combine them if TRANSFORM is nil?

[minad]

Yes, sure. Then the feature would not be part of consult--read but for example of consult--grep-format, where the group is computed and attached as property to the candidate. But then I think the addition will be too ad-hoc and non-customizable.