Built-in support for ivy-rich?

[rgrinberg]

https://github.com/Yevgnen/ivy-rich is quite a useful extension that massively increases its usability. However, there's one catch with using ivy-rich at the moment - it's not possible to narrow candidates based on the additional columns. The author of ivy-rich hints that some changes to ivy might be needed to support this. Were such changes considered?

[basil-conto]

The author of ivy-rich hints that some changes to ivy might be needed to support this. Were such changes considered?

I, for one, am not aware of what changes would be needed.

[basil-conto]

See also #2780 for adding Marginalia support.

[minad]

Filtering based on additional columns/annotations is not a good idea, since this can be potentially very expensive. The candidates are generated/filtered/sorted first and then annotations are only shown for the displayed candidates. Annotations are not meant for more than that.

Note that Emacs has annotations built-in via the annotation/affixation-function. Default completion is also unable to filter by annotations. And neither ivy-rich nor my Marginalia package support it for the given reasons.

However in case you want to really filter/search based on the annotations you may create a buffer upfront from all candidates (ivy-occur) and then search manually inside that buffer.

[rgrinberg]

Sure, it isn't efficient, but it can be very useful. For example, I often find myself wanting to restrict the list of buffer candidates by the project name, or major-mode. Is there another way to accomplish this?

[basil-conto]

I often find myself wanting to restrict the list of buffer candidates by the project name, or major-mode. Is there another way to accomplish this?

FWIW, I would use ibuffer for this particular purpose. (See the docstring of ibuffer-mode for an outline of its features in case you're not familiar with it.)

[rgrinberg]

Thanks for the suggestion. I suppose counsel-ibuffer is usable for this, but I'm still not convinced it's a general purpose solution. It seems useful to be able to search metadata that's attached to entries. For example, if I'm searching functions, it would be nice to search their documentation strings. I understand the potential for degraded performance, but this feature could easily be opt in.

[minad]

@rgrinberg I tried to implement this feature once in my Consult package (minad/consult#67). I made a consult-help command which was supposed to work like an enhanced describe-symbol/describe-function command, allowing to search the documentation strings. From my experience it was too slow to be even considered for addition to the package. Maybe there are ways to make it work better with extensive caching or other tricks, but I don't see this working well for general annotations in the style of ivy-rich/Marginalia.

[rgrinberg]

Daniel Mendler ***@***.***> writes:

@rgrinberg I tried to implement this feature once in my Consult package (minad/consult#67). I made a `consult-help` command which was supposed to work like an enhanced `describe-symbol/describe-function` command, allowing to search the documentation strings. From my experience it was too slow to be even considered for addition to the package. Maybe there are ways to make it work better with extensive caching or other tricks, but I don't see this working well for general annotations.

Yes, I don't see an easy way of making this work for things like documentation strings. Though it would be highly useful if there was a way despite the effort. Filtering by documentation strings sounds very useful! But perhaps we're trying to generalize my request prematurely? Just because the feature does not scale for all sources, does not mean it is not useful. I don't know about your usage patterns, but the number of buffers I usually have open will not make it prohibitive to search by project or major mode. There's plenty of other examples too: bookmarks, recent files, imenu entries, all come to mind.

[minad]

In the case of documentation strings, I don't think you get something usable with the available infrastructure (annotators, ivy filtering, completion style filtering). This is better solved by (rip)grepping over the emacs code base or whatever other code base you are interested in :)

In the case of bookmarks, buffers, etc., I agree with you. In those cases filtering by metadata is possible and will be fast enough to work well. In the context of the Orderless completion style we discussed if it makes sense to add additional metadata to candidates which is used for filtering (oantolin/orderless#30). Of course one could try to reuse the annotation function to obtain the metadata.

Then I've seen another approach in the context of the helm-bibtex/ivy-bibtex/bibtex-completion/bibtex-action package. There the candidate strings have hidden metadata strings attached (author=... journal=...). In this case the annotation function is not used; the data is attached right away during the candidate generation.

[basil-conto]

In the case of documentation strings, I don't think you get something usable with the available infrastructure (annotators, ivy filtering, completion style filtering). This is better solved by (rip)grepping over the emacs code base or whatever other code base you are interested in :)

(or C-h d (apropos-documentation))

[seagle0128]

Just FYI

With all-the-icons-ivy-rich, you can get more powerful features.

[a13]

In the case of documentation strings, I don't think you get something usable with the available infrastructure (annotators, ivy filtering, completion style filtering). This is better solved by (rip)grepping over the emacs code base or whatever other code base you are interested in :)

ever tried to use, say, Chrome settings interface? It has incremental search not only for names but for docstrings as well. Very handy.

[a13]

I often find myself wanting to restrict the list of buffer candidates by the project name, or major-mode. Is there another way to accomplish this?

FWIW, I would use ibuffer for this particular purpose. (See the docstring of ibuffer-mode for an outline of its features in case you're not familiar with it.)

I often find myself wanting to restrict the list of buffer candidates by the project name, or major-mode. Is there another way to accomplish this?

FWIW, I would use ibuffer for this particular purpose. (See the docstring of ibuffer-mode for an outline of its features in case you're not familiar with it.)

to use ibuffer you have to think about all the stuff beforehand, it's not always possible, you may change your mind in progress of switching etc. The whole point of Ivy (to me) is it brings laziness to Emacs.

[minad]

@a13 Of course it is handy to search documentation and metadata during completion. All I am claiming is that it won't be fast, as long as you don't add some kind of caching/indexing. Filtering buffers by metadata in contrast is feasible without performance issues. I've made a toy implementation which allows filtering by completion category specific metadata, buffer content, major mode, documentation strings etc, depending on what you complete. I fully agree with you that the nice thing about completion+actions is that it allows you to be lazy and change your mind during the process. It brings a lot of flexibility.

[a13]

All I am claiming is that it won't be fast, as long as you don't add some kind of caching/indexing.

well, ivy supports dynamic collections, so I don't think it's a big issue.

Another example - counsel-yank-pop opens in 0.8 sec for me (until I hacked it for using -distinct instead of cl-delete-duplicates it took 1.5sec), but it saves much more time, so I use it anyway.

[minad]

well, ivy supports dynamic collections, so I don't think it's a big issue.

You are right that one could implement a command which performs the search in the background. All I said only applies to the synchronous filtering which is usually performed by most commands, in particular the builtins like describe-variable, describe-function, etc. For these commands it would be quite handy to have a filtering by documentation.

Another example - counsel-yank-pop opens in 0.8 sec for me (until I hacked it for using -distinct instead of cl-delete-duplicates it took 1.5sec), but it saves much more time, so I use it anyway.

Oh, that's quite slow. Do you use an excessively large kill ring? You could also try delete-dups which is O(n) and which is a builtin.

[a13]

You could also try delete-dups which is O(n) and which is a builtin.

I'm aware about delete-dups and know that consult uses it, the problem with that is doesn't support custom comparators. Otherwise it would be not faster than -distinct.

Do you use an excessively large kill ring?

well, when your emacs-uptime is weeks and even months long - it can't be the other way, about 5000 elements so far, some of them are kilos long :)

All I said only applies to the synchronous filtering which is usually performed by most commands, in particular the builtins like describe-variable, describe-function, etc.

no one stops you from having an async version of these

[cjauvin]

I have proposed a simple modification to ivy which allows to filter based on additional columns supplied by ivy-rich (or any user-supplied transformer function), on a per-command basis (i.e. in my personal case I use it only to modify the behavior of ivy-switch-buffer, as the extra cost of computing the transformations on the fly is low enough to be acceptable, which might not be the case with other functions).