Have the cool kids moved from Ivy & Counsel to Vertico & Consult?

When I started using Emacs again in 2020, everyone seemed to move from Helm to ivy & Counsel, and I also did, and never looked back. A year ago I watched a video from Protesilaos about Counsel, Vertico, Embark and Marginalia, and I was stunned. So I gave it a try. But even little things like searching for commands via "M-x", which is done in ivy/swiper in a fuzzy way where I can enter "helm ugt rifle" to find "ugt-helm-file" was not possible in Consult. I have the feeling that all cool kids are moving to Vertico + Consult. Am I wrong?

You need to use something like orderless ([https://github.com/oantolin/orderless](https://github.com/oantolin/orderless)) for fuzzy searching.

Don’t know. depends on the completion style (e.g. build in flex or try orderless)To be honest the effective differences between the completion frameworks are now tiny… Ivy works much better with tramp than the others though (probably caching which e.g. vertico does not do because it aims to be a close as possible to the build in completion) and in general ivy does everything I need.

It is true that there is a lot of chatter about `vertico` and friends on this subreddit and elsewhere. But I have yet to hear a compelling reason to switch from `ivy`. Can anyone tell us what we would win by doing so?

I switched from ivy/counsel/swiper to vertigo/consult/marginalia, in part because of this [quote from Vertigo](https://github.com/minad/vertico#alternatives): > Vertico aims to be 100% compliant with all Emacs commands and achieves that with a minimal code base, relying purely on completing-read while avoiding to invent its own APIs. Inventing a custom API as Helm or Ivy is explicitly avoided in order to increase flexibility and package reuse. Due to its small code base and reuse of the Emacs built-in facilities, bugs and compatibility issues are less likely to occur in comparison to completion UIs or full completion systems, which reimplement a lot of functionality. My switch was due to what I perceived as the long-term maintainability of the vertigo/consult/marginalia ecosystem; even though _for my use cases_ there's a present feature parity between the two ecosystems.

Has anyone tried both vertico and selectrum? Any major differences?

Also need to add orderless-flex to orderless-matching-styles. Edit : need flex to match non consecutive char as explained below.

It seems likely that selectrum will be deprecated in favor of vertico. [https://github.com/minad/vertico/issues/237](https://github.com/minad/vertico/issues/237) See also the first link he includes for the justification.

I asked the same thing a while ago: https://old.reddit.com/r/emacs/comments/ryqfz1/vertico_extensions_demo/hrru7rp/ My conclusion is that Vertico is now a pure upgrade over Selectrum.

I haven't switched yet. Is there a `ivy-occur` equivalent?

I believe that's handled with Embark (via consult-embark?).

I get that all these packages are trying to provide modular completion behaviors but why not provide a combined package with a standard set of common configurations that users can switch among to see useful behaviors without having to figure out all of the configurations and inter-relations themselves?

I'm not cool yet. I'm still using ivy/counsel/swiper because it works well for me.

IMHO, the switch isn't as big as from Helm to Ivy. I tried Ivy most because of its leaner UI taking less space, and it is easy enough to make it get along with Helm. The new system, while not necessarily hard to get into, require a bit more effort for seemingly fewer features (for now). Personally, I don't really care about the philosophies of all 3 system, my current config is still a mix of Helm(10%) and ivy(90%), it is because some people had implemented some features I wanted in both of them. I would gladly have Vertico/Consult joined in the mix if some features (that I like) appear in the new system.

Selectrum is the bomb :) .. selectrum orderless marginalia is fantastic.

Not sure if everyone has but I sure have XD, Vertico is a amazing completion system.

`consult-line`

I think that's what embark-export does?

I think your best bet for that would be doom emacs, which lets you select any of vertico/ivy/helm as your completion backend (in `.doom.d/init.el`) and provides some unified keybindings that are consistent across all three. It's a big, far reaching ask for a dedicated package to maintain that in isolation, completion is a feature with a fair amount of surface area.

I've tried moving over and although some things seem slightly nicer but I'm also missing functionality I really enjoyed with ivy/helm. One of them for example is that I had set up ivy so that while switching buffers I could use C-k to kill a buffer. I haven't figured out how to do this with the vertico+marginalia+etc ecosystem. So I don't feel as strongly about this move as the one from helm to ivy.

I think Protesilaos uses Embark to accomplish these kind of actions.

I like the default fuzzy completion of ivy which helps me to avoid unnecessary keybindings. For example, M-x p-l-p can do M-x package-list-packages. In this way for operations that are not used daily I use functions rather than keybindings. It should be possible also in vertico, but I probably have to use another package suh as orderless, or smth. else.

You would need embark as part of the etc in the ecosystem. If you're interested this post should help: https://karthinks.com/software/fifteen-ways-to-use-embark/

The vertico-multiform feature is fabulous and has no equivalent. It permits making completion as in-your-face or as unobtrusive as you want depending on context. Say I want M-x to use posframe in GUI (but not terminal), buffer operations to use unobtrusive display (no big minibuffer), and imenu commands to use grid display. Vertico makes this easy. I managed to get rid of tons of fragile Helm and Ivy hackery by switching. If you don’t mind the way Helm or Ivy work out of the box, then switching to Vertico might not be worth it. On the whole, Vertico’s flexibility and general quality is so high that it should be considered for inclusion in Emacs core and should be turned on by default. In unobtrusive mode, it’s not very different from vanilla and will not mess up muscle memory — it just provides nice completion without fuss. It handily outclasses built-in options like ido, fido, and icomplete. A bunch of the arguments about modernizing Emacs might even go away.

Isn’t selectrum superseded by vertico? Funny: selectrum claimed to be faster than ivy but was until recently actually slower …

Vertico is very slow over tramp unfortunately…

Here I am still using Helm....

Doom Emacs has switched to Vertico & Consult by default. It is cool so the cool kids have switched.

Is it? I don't observe issues with Doom and there are also no open reports on the issue tracker about tramp.

You may want to check your Vertico config, as there is no reason for Vertico itself to be any slower than the alternatives. If it's public, I could skim it.

I move directly from Helm to vertico+consult+marginalia. My Emacs starts as quickly as vim so I use it even without daemon mode

The big advantage is that vertico etc. use the standard emacs APIs and work everywhere. With ivy you always need a "customized" variant. For example, ivy: counsel-describe-variable -> with vertico you can just use the normal describe-variable and you get all the goodies, vertico/orderless/marginalia etc.

>Personally, I don't really care about the philosophies of all 3 system It's not just about philosophy, with ivy and helm you always need customized commands because they don't just use the basic emacs apis. With Vertico you can just use your "normal" commands and vertico/orderless/marginalia do their jobs.

Yes. Selectrum might be deprecated in favor of vertico if there is no useability disadvantage. https://github.com/minad/vertico/issues/237

because it's unclear what that "common configuration" should be or what even the terminology should be. with every new generation of these solutions the picture is getting clearer and solutions are getting more and more crystallized. but I agree, that it's baffling to see that "end-users" are exposed to such details, meanwhile in other editors it became mainstream to have a coherent, full featured, fuzzy, intuitive completion/filtering interface out of the box. while those solutions are hardly configurable, they are so good as is, that it doesn't even occur to most of their users that they might want to configure it. I think the reason why Emacs is so different, that it's practically the only editor, which has the unique design constraint of providing feature parity between TUI and GUI modes, while utilizing GUI capabilities, but with graceful degradation in TUI mode.

have you also switched to straight.el? because a big part of the reduced startup time might be the fact that your packages are compiled (and even native-complied, as your tagline suggests).

Indeed that is very useful ; though in practice this might only rarely be needed / there might be situations where this is actually useful: Handel the cases you can / want, otherwise Hand it to standard completion. But to be clear: I very much like both, ivy and vertico which is excellent; but I don’t like this „This is the new package, what everybody was using before is garbage!“ - attitude.

I haven't practiced embark much yet, but don't you have to explicitly invoke embark first, while you are in the buffer selection mode, before you can say what other operation you want to apply? I mean, with embark you have a more composable solution, at the cost of extra keystrokes.

ido and smex is what the coolest kids are using, though I use ivy for imenu as well

Embark provides two related commands: - `embark-export` which attempts to make a buffer listing all the completion candidates in a major mode that is specific to the type of candidates; for example it uses dired for files, ibuffer for buffers, grep-mode for search results from consult-(rip)grep, a customize buffer for variables, etc. - `embark-collect` which lists all completion candidates in a buffer in Embark Collect mode, which lets you mark candidates and act on them in a dired-like fashion. This Embark Collect mode is also used by `embark-export` as a fallback if it doesn't know what specific major mode to use.

There is no conflict between offering a turnkey system and allowing for any level of customization at the same time. Additionally, my suggestion was to have configurations like the equivalent of Emacs themes that could be loaded and tried out without understanding any settings, package combinations or algorithms. All of that would still be there for those who want to explore rather than just gain productivity for their work.

That's just the builtin "partial-completion", no need for another package: `(setq completion-styles '(basic partial-completion))`

Dont most end up using consult anyway? I don't see a difference in that case. It is like the ivy situation except now it's consult instead of counsel.

Me too. It works for me, so there is no real reason to change.

Do you use company/autocomplete or semantic mode? My emacs session with tramp hung when trying to auto complete. Also rainbow delimiters and highlight-indent-guide do not work. Do you have any specific tramp config

I hear this thing about native APIs being thrown around especially in the last two years and I want to ask why does it matter? If the projects were to be up streamed I get it. But they are not. What actual advantage is there from a user's point of view. Especially for vertico and selectrum wouldn't working on emacs's built in Icomplete or Fido mode be better option if one was to go all native. It is a genuine question, what am I missing.

Same here, with the addition of company or auto-complete. I don't actually remember which. For an old curmudgeon, what are the benefits of trying one of these frameworks out?

No, I use build-in package.el + use-package. All my packages are compiled as well

>Say I want M-x to use posframe in GUI (but not terminal), buffer operations to use unobtrusive display (no big minibuffer), and imenu commands to use grid display Is your config code available for this? I'm curious.

Yes and no. From consults readme: >Furthermore Consult provides multiple search commands, an asynchronous consult-grep and consult-ripgrep, and the line-based search command consult-line. Some of the Consult commands are enhanced versions of built-in Emacs commands. Consult is also more general: >Consult is fully compatible with completion systems based on the standard Emacs completing-read API, notably the default completion system, Vertico, Mct, Icomplete and Selectrum.

The biggest advantage for me are two things. 1. if I find a new package, the whole vertico/orderless/marginalia etc stack works out of the box with it, if the pckages uses completing-read. No need to helmize everything. 2. you can plug together multiple packages that dont strictly depend on each other. With helm there are many helm specific extensin plugins. For example marginalia can be used standalone or together with vertico, they dont depend o each other and maybe one day somebody writes an even better package than vertico, the marginalia would still work with it.

I know that consult is more general but IMO if you're thinking of switching from ivy+counsel to vertico+consult, I see no difference in practise. In both cases, you have two packages: a completion UI and complementary/enhanced commands to go with the UI.

No the problem with ivy is the same as with helm, you always need adapted commands. If you install a new package without explicit ivy support it will not work flawelssly. Vertico will. Consult is not like counsel where it replaces a lot of commands. For example here are all the functions I personally use from consult: (use-package consult :bind (("M-y" . consult-yank-from-kill-ring) ("S-C-f" . consult-ripgrep) :map isearch-mode-map ("C-h" . consult-isearch-history)) Consult adds features but isn't needed for vertico to work with the the standard ones. Wih ivy you need counsel, with vertico you don't need consult.

>If you install a new package without explicit ivy support it will not work flawelssly. Vertico will. This is too strong of an assertion, IMHO. ivy works just fine with regular old completing-read, counsel is only really necessary if you want all the fancy-pants stuff. At least, that was my experience/what I remember. >Wih ivy you need counsel, with vertico you don't need consult. Same as above. The only reason why I preferred ivy-read over completing-read was because the former had keyword arguments which is a lot more friendly than positional arguments. It is not like the new stack does not have agreed upon conventions either. For embark to play nicely with consult--multi, they have an agreed upon convention to get information about the candidate. (The reason, BTW, I looked into this was to see how consult--multi coped with completion-styles-override.) When reading the consult source code, I realised that consult is its own beast. Yes, consult is built on top of completing-read, but is consult--read any different from ivy-read? I don't see a difference in _practise_. It also surprised me to see consult increasing the GC threshold at places as well. Sorry, but my impression is that consult is its own beast, much like ivy. [ Sorry if I got the function names wrong. ]

The relevant snippet looks like this (example changed to my actual display setup: file operations use unobtrusive mode, buffer operations use flat ido-style, and a few other self-explanatory things). Posframe display requires vertico-posframe package. (vertico-mode 1) (vertico-multiform-mode 1) (setq vertico-multiform-commands '((consult-imenu buffer indexed) (project-find-file buffer indexed grid) ("persp-.*" flat) ("cider-.*" flat))) (if window-system (add-to-list 'vertico-multiform-commands '(execute-extended-command indexed posframe)) (add-to-list 'vertico-multiform-commands '(execute-extended-command unobtrusive))) (setq vertico-multiform-categories '((file unobtrusive) (buffer flat (vertico-cycle . t)) (consult-grep buffer))) Display customization is documented in the Vertico README: https://github.com/minad/vertico/#configure-vertico-per-command-or-completion-category

Whats the point of counsel-find-file etc. then if it's not needed? Genuine question. Generally you "need" counsel to adapt all the existing functions. Consult simply doesn't do it. It's purely an addition to add fancy stuff like automatic preview of results when searching for example.

Wow, so raxod is looking at dropping Selectrum even. I guess I will have to look into Vertico then :0

counsel-find-file is mainly for ivy actions IIRC. Which is one of the problems with ivy---if you want actions, you need to make a special command AFAIU, and this is what embark solves by relying on completion category, if I'm not mistaken. This is why marginalia package is highly recommended, before marginalia was released, embark had some overlapping code with marginalia.

I'm not sure what you mean. Orderless, as the name indicates is all about out of order matching. The default configuration will allow "hel ugt rifle" to match `ugt-helm-rifle`, as in OP's example. Adding `orderless-flex` to `orderless-matching-styles` adds a different capability: matching characters _in order_, but _non-consecutively_. So, with `orderless-flex` you can type `rfl` to match `rifle`. And different space-separated components still match in any order so, `hlm ugt rfl` would match `ugt-helm-rifle`.

In Emacs you never need more than one keystroke if you don't want to need more than keystroke. ;) A keyboard macro is a simple solution here: if you bind `embark-act` to `C-.` you can simply bind `C-k` to `C-. k`: (define-key vertico-map (kbd "C-k") (kmacro "C-. k"))

Sorry for confusion. I meant to say need -flex for fuzzy search, not what OP asked.

People keep telling me to ditch helm, and I wouldn't mind using something where the official documentation is actually readable, but switching seems like so much *work* ...

>No need to helmize everything. Well, that might just be the reason I needed to finally switch.

Thank you for the advice and the great packages and the active support! I think I never saw that kmacro trick before. I'm "only" learning Emacs for 3 years though.

No I think the build in completion can be a bit slow because it refreshes more often.

Why would default completion refresh more often? Refreshes hit the Tramp cache anyway, so the UI does not make a difference.

[deleted]

[deleted]

Someone actually personally tells you to ditch a package? How do you know them and how many are these people?

Themes but for settings, interesting. At least, some packages could have a meta-customize option that sets many of its other options.

But the configuration of these packages does not take much at all. It is more a question of what you want you want to turn on. See for example: https://www.emacswiki.org/emacs/SetupEl#h5o-22