Comparison to Ivy in README is a bit outdated

[raxod502]

So even when I wrote it, the Ivy section of the README was somewhat questionable in its neutrality and correctness. But now it's definitely out of date. It claims Selectrum is only 2,000 lines of code when it's about 3,000 now---and more generally, the argument that the codebase is much smaller than Ivy's is not so correct anymore.

We also don't have any mention of the broader ecosystem in which Selectrum is a part, which is a sort of replacement for the Ivy/Counsel/Swiper suite. I still believe that the Selectrum way is nicer for various reasons, but it would be a good idea to rewrite this section accordingly. The advantages of Selectrum nowadays would probably be better summarized as:

• we try really hard to develop standard interfaces, including conforming to the ones that come with Emacs already
• the packages are more composable, interchange, modular, etc.
• we try to avoid making design decisions that will bite us later, even when it would be good for user experience, in favor of waiting to develop a more robust solution using an approach that takes a while to figure out (several of the packages that can be composed with Selectrum have been developed this way)

[clemera]

To expand a bit on the composable, interchangeable point: Selectrum is mainly a better UI for the default completion API. Ivy also handles part of the API but it deters from it in ways that requires commands which want to use these features to use ivy-read and because of that the extra features are bound to the ivy UI.

[minad]

Note that it is also a significant advantage for correctness when I am able to test packages against Selectrum, Icomplete-vertical, default completion etc. While it is a complication to test against multiple implementations, and a tiny bit of integration code is needed in Consult and Embark, the resulting code quality and robustness is greatly enhanced. A decoupling of the components is enforced by design.