[request] allow :lookup in consult--multi sources

[45mg]

When defining a source, it might make sense to reuse existing state functions (eg. consult--file-state if the source is a list of file names). However, we might also want to display the candidates in a different form than what is passed to the state function (eg. abbreviate the file names). In consult--read, the :lookup property enables this; in consult--multi, we are forced to create new state functions that wrap the --preview and --action functions used in existing state functions, calling the function that would normally be passed through :lookup on each candidate before passing it to the wrapped functions.

Since this is rather inelegant, and difficult to get right, would it be possible to support :lookup in consult--multi?

[minad]

Yes, we could add a :transform function, which take a candidate string and returns a transformed string. A :lookup function does not make sense though since no :lookup in the candidates list will be needed. Patches welcome.

[minad]

@45mg Thinking about this again, I remembered that we don't need such a function, since one can always attach the multi-category text property to a candidate, for example multi-property = (cons 'file the-actual-file-name) or multi-property = (cons 'buffer the-actual-buffer-name).

[45mg]

That works fairly well. The only issue I've faced while doing this is that if you use an :annotate function, it gets the multi-category value rather than the candidate string itself, so now you need to figure out a way for it to get the candidate from that value (I used an alist of multi-category values to their strings). So, not a complete solution, but still better than having to define wrapped state functions.

[minad]

Mathew ***@***.***> writes:

This works fairly well. The only issue I've faced while doing this is that if you use an `:annotate` function, it gets the `multi-category` value rather than the candidate string itself, so now you need to figure out a way for it to get the candidate from that value. I resolved this by having an alist of `multi-category` values to their strings. Overall, it's still an improvement, though.

You could also attach a text property to the actual candidate string (the cdr of the multi-category property).

[45mg]

That would work for the filename case I was originally describing, but now I'm writing a source that handles org-agenda headings with consult--jump-state similar to how consult-org-heading does. So the cdrs are markers from the org-marker property, not strings. (consult-org-heading uses the :lookup approach.)

[minad]

Mathew ***@***.***> writes:

That works for the filename case I was originally describing, but now I'm writing a source that handles org-agenda headings with `consult--jump-state` similar to how `consult-org-heading` does. So the cdrs are markers from `org-marker`, not strings. (`consult-org-heading` uses the `:lookup` approach.)

Oh, this is not correct. The multi-category cdr must be a string.

[45mg]

...oh. So, am I back to wrapping consult--jump-state, then? And is there a reason why they must be strings?

[minad]

Mathew ***@***.***> writes:

...oh. So, am I back to wrapping `consult--jump-state`, then?

Yes. But your original suggestion (of a lookup function or transform function) wouldn't work either. There you would transform the candidate to a marker and then again lose access to the metadata needed by the annotation function.

[minad]

Hmm, on the other hand, the lookup/transform function may not transform the argument of the annotate function, in consistency with how consult--read (and consult-org-heading).

This means a potentially new transform function would only transform the argument of the state function. At this point, we can simply keep things as is. You can wrap or compose the state function. This is not more complex than using a separate transform function. I close this.

[45mg]

Just one more question then - why must the cdr of the multi-category text property be a string only?

[45mg]

Oh, never mind - it's a marginalia thing. Got it.

[minad]

I think in limited scenarios we can allow multi-category to handle non-strings in the cdr. But it will need special handling in Embark and Marginalia. See the discussion #979.