Consider a completely customizable candidate display

[Luis-Henriquez-Perez]

As I was working on #200, an issue that would involve customizing the display of indices I wondered about the design of things.

OK, so if we take ivy as a precedent, we can see that users will want to start adding metadata to decorate candiates.

Below is an image from ivy display customization done with ivy-rich.

Given this why don't we create a generic `selectrum-display-candidate-fn'? This function would be applied to all the candidates to compute their display. The function would take in the displayed index of the candidate as well as the candidate itself. By default it returns the candidate as a string, so that candidates will display as they do now by default.

This is a rough idea. The advantages of doing this would include:

(1) not doing duplicate work

Right now #200 will improve selectrum, however I still have lingering questions about how that will play nicely with adding an icons, candidate descriptions (like docstrings), etc.

(2) giving full customization to the user

This would likely obsolete selectrum-show-indices.

An example

;; A rough draft of a function to be used with `describe-function' to display documentation.

(setq selectrum-display-candidate-fn
      (lambda (index candidate)
        (format "%2d %20S %100s" 1 candidate (s-truncate 80 (documentation candidate) "..."))))

(funcall #'selectrum-display-candidate-fn 1 #'number-sequence)

; =>
" 1      number-sequence                      Return a sequence of numbers from FROM to TO (both inclusive) as a list.\nINC ..."

[okamsn]

See this related discussion: https://github.com/raxod502/selectrum/issues/181.

[clemera]

Also relevant: #14

[minad]

I think this has been resolved by marginalia. The marginalia annotations are as rich as the ivy-rich annotations and you can add your own if you need more. It is only possible to add annotations after the candidate however, prefix annotations are only supported when the affixation-function becomes available.

[aspiers]

Awesome! Before closing this issue, please consider updating the selectrum README to mention that marginalia is an alternative to ivy-rich. I had previously searched the README for a mention of alternatives to ivy-rich but there were none, so I failed to notice the mention of marginalia. Mea culpa for not reading carefully enough, but it is a long README so I think mentioning ivy-rich would help others find this great alternative.

[clemera]

As described with marginalia you can now define your own annotations. Support for affixation function was also recently added to Selectrum. Can this be closed?

[minad]

@clemera We have not yet implemented affixation-support in marginalia, but we probably will do that at some point. The ugliness with affixations is that they destroy the nice composability of the annotation functions since we are now acting on nested lists instead of these simple strings. Therefore I haven't added them yet. I did some preliminary experiments in https://github.com/minad/marginalia/tree/affixation. From my side this can be closed, but let's wait what @Luis-Henriquez-Perez says.

[clemera]

The ugliness with affixations is that they destroy the nice composability of the annotation functions since we are now acting on nested lists

If I'm understanding you correctly I have good news, this will get fixed.

[clemera]

Oh I think I got you wrong, anyway now you are up to date with changes to affixation :smile:

[minad]

Yes, I did not mean there is an issue. It is just that the functions do not compose as nicely anymore. Before we had String-> String, now we have List String -> List (String, String, String)

[Luis-Henriquez-Perez]

I'm fine with closing this issue if marginalia resolves this. Even better if another package can handle this and selectrum can focus solely on completions.

[clemera]

Okay, I will close this then, as thanks to @minad there exists now a package dedicated to this purpose.