search

minad / affe

:monkey: affe.el - Asynchronous Fuzzy Finder for Emacs
GNU General Public License v3.0
221 stars 8 forks source link

Can consult be an optional dependency #24

Closed pushqrdx closed 2 years ago

pushqrdx commented 2 years ago

I really love how modular the rest of your packages are so one can match and use the perfect combination that suits their needs, and i wish affe was similar. Is it possible to have consult as an optional dependency?

minad commented 2 years ago

No, affe uses the async feature of the consult--read API. This API requires a tiny bit of completion UI integration code (e.g. consult-vertico.el, consult-icomplete.el, etc), which provides for example UI refreshing. Duplicating all this code would be a wasted effort.

In order to properly modularize the ecosystem further, one should extract the core Consult APIs to some separate package, let's call it enhanced-completing-read. This package would then provide replacements for consult--read, consult--multi and consult--prompt, since these are the relevant APIs. Then affe, consult and all the other consult-* packages could dependent on this enhanced-completing-read package instead of consult.

For now I haven't seen the need for such a split so far. It does not hurt to install Consult, since it is a non-intrusive package. It does not add modes, it does not add keybindings etc. On the other hand it is understandable that it does not feel reasonable to install all these consult-* commands if you don't intend to use them and only intend to use affe-grep.

I admit that I underestimated that people are eager to use an enhanced-completing-read API and as such like to depend on Consult to implement packages with asynchronous commands etc. So it may be a good idea to make this split at some point, extracting the enhanced-completing-read API. But one should also keep in mind that I intentionally made the consult--read API internal - it should really only be used by new packages which make use of Consult-specific features (like the aforementioned async feature used by affe). For all other scenarios it is much better to just use completing-read directly, ensuring perfect modularity and avoiding the Ivy/Helm ecosystem schism. I want to encourage this by not providing a public consult-read API. This situation would change with the extraction of enhanced-completing-read.

I hope this explains the current design - it was partly intentionally made like this and it is partly grown of course. If you have further questions, feel free to ask!

pushqrdx commented 2 years ago

@minad makes sense! and thanks for the detailed explanation