Replacing packages with more "stripped down" packages

When I started using Emacs I was following the setup outlined by [System Crafters](https://www.youtube.com/c/systemcrafters), which I still think is a really good introduction. But, over the last few months I've started to replace packages with more "minimalist" or "stripped down" packages. I've switched from [Ivy](https://github.com/abo-abo/swiper) and Counsel to [Vertico](https://github.com/minad/vertico) and [Consult](https://github.com/minad/consult), and recently I switched from [company](https://github.com/company-mode/company-mode) to [corfu](https://github.com/minad/corfu) for auto-completion. I think a lot of members of the Emacs community have done the same. My question is what package have you replaced with a more "minimalist" package in your emacs config? What were the major factors that made you decide to switch?

Yasnippet -> Tempel

I've been considering a switch from Org-Roam to Denote... but I'm afraid to give up my graph-ui

I am using both. The main reason that I keep yasnippet is eglot completion. They are from the same author, and they work really well together.

I use lsp, because lsp-ui works better for me. Both yasnippet and tempel could work independently from lsp servers

Not sure if this counts, but I recently switched from vterm to EAT (https://codeberg.org/akib/emacs-eat) and am doing almost everything in eshell.

Why? What do you actually use it for?

Vertico with Fido-vertical

Not subop, but I'll share my experience It's great for discoverabiliti and taking quick look at what is connected by paths longer than one. I'm mostly using it just before exam to quickly review topics by asking one simple question "why is X connected to Y and how?"

I use vterm for eshell visual commands at the moment, and EAT looks interesting, thanks for sharing!

projectile -> project.el lsp-mode -> eglot org-roam / denote -> [my own stripped down clone](https://github.com/vifon/zettel2) As for the popular vertico+orderless+consult+embark+marginalia stack, I wouldn't call them stripped down, but rather modular. For all intents and purposes, this is the most feature-rich setup I've had since Helm. And much better designed and easier to customize too.

I know this is a current trend, but why give up functionality you need and use for minimalism? Even if you don't give up any funtionality, why go trough the hassle of reconfiguring and relearning something that is already working?

For me, I simply enjoy this

Anyone knows a builtin alternative to global-anzu-mode, I just want to see the number of total matches

Great isn’t it. I used ivy and counsel, because they were newer than helm. Now you are suggestions other packages to try. Installing all these new packages isn’t what I’d call minimal, but if you use something like straight as a package manger you don’t really want to wait thirty minutes for all the new packages to download install and compile, so I’d like to do more with less, but not for a minimalist aesthetic

I suppose people doing that are just *eternal hobbyists*, if you use Emacs to get the job done - there's not so much time for such experiments.

ivy + counsel -> vertico + consult company -> corfu flycheck -> flymake lsp-mode -> eglot as I learn more about emacs and what it can do, I'm tending to prefer built-in features over external ones and libraries which leverage those built-in features over libraries which use completely custom solutions and occasionally require adapter glue.

If you're not looking to replace anything, maybe the built-in `M-x how-many` is enough?

is there any way to make eshell run normally when reading large files? I tried using it but whenever reading a large file the whole emacs process stops IDK why.

I just started using Denote and love it. The feature that won me over was that it was file type agnostic. If you do give it a try don't give up without trying it with [consult-notes](https://github.com/mclear-tools/consult-notes).

I feel seen.

I just discovered (setq isearch-lazy-count t), which does the exact some thing!

>why go through the hassle of reconfiguring and relearning something that is already working Many "already working" solve-everything packages are brittle in the long term, since they operate as their own standalone code islands. Once maintenance slows or stops, they start breaking. Smaller packages that do most or all the same job using emacs builtins and APIs are in my experience more likely to be working well after 2 or 3 major Emacs releases, even if their maintenance levels drop. For me, favoring smaller packages which lean as much as possible on builtin functionality is an investment for my future self.

This looks neat, can it run htop or handle opening vim? These are my "benchmarks" if it would work as my day to day terminal.

I actually wrote a substitute for a pretty large and largely unmaintained package (outshine) called [outli](https://github.com/jdtsmith/outli); it relies heavily on outline-mode and not much else.

It's the holiday season. People have time on their hands.

Basically yes. It doesn't show every frame, so htop might look laggy, and there's a bug with resizing htop specifically. Also the Emacs keybindings can interfere with vim commands. But that's a solvable problem. Definitely try it out if you can, it's smooth.

There's a few possibilities: 1. Long lines. Try upgrading to emacs 29 or there's a package that might help (idk the name) 2. Maybe the file is getting stuck in a garbage collection loop? Check gc-cons-threshold and maybe multiply it by 100. 3. Try not to use large files at all, or filter them before they get to eshell. Example: `/usr/bin/grep 'string' file.txt` rather than cat|grep.

Can you describe to me, an lsp user and yasnippet non-user, how those packages can work together? I don't know the use case.

thanks.

Firstly, I was not sure that the OP is accurate. I don't know that vertico/consult/embark/marginalia/corfu etc., is "stripped down". What they are though, is integrated into standard Emacs, and modular, so you can use them separately in any combination you like, and any code written for standard Emacs completion will use them without any modification required. This was less true for helm/ivy etc.. So for me, that's the reason - these newer packages are, from some perspectives, *done right*. For that reason I think they have a stronger future ahead of them, and are a better way to go.

Just a small heads up regarding project.el for C/C++ users: projectile has a custom function to jump between hpp and cpp files (`projectile-find-other-file`), project.el does not. While theoretically this can already be done without projectile etc. via `ff-find-other-file` projectile makes it work out of the box without any configuration while getting ff-find-other-file to work the same requires you writing the lookup function yourself.

I don't use all of these but some that I know of are: evil -> meow undo-tree -> vundo smartparens -> puni isearch -> ctrlf org-mode -> howm

I'm using consult+vertico, but the lines of code of them are similar to ivy, to be fair.

Do you mind to give a comparison between these two? Both are relatively new, and not much information about them.

Oh wow, thank you for this recommendation! For some reason I haven't been able to get colors to work, but eat is wonderful regardless. EDIT: Found the issue! Seems to be a problem with fira-code-mode, even after it's been disabled colors remain broken in eat and eatified eshell buffers.

You need to include the terminfo files. The recipe for straight is in the Readme, it works with Elpaca too.

I don’t care to the slightest. Helm go brrrrrr

Ah, the terminfo files were fine, I use borg so it was no issue. Turned out to be a strange issue with fira-code-mode -- even after disabling it, the colors remained gone if it had ever been enabled in the buffer which made me have to bisect my config by commenting/uncommenting it to find the problem \^\^'

I keep meaning to get around to trying outli out, it looks wonderful.

I've experimented with `fido-vertical-mode` a little bit and I want to like it, but it's really just tangibly so much less responsive than `vertico-mode`.

People often use more than they need. lsp-mode has a lot. There's now a built-in that's sufficient for people's needs. They can then reduce the number of external packages. > .. why go trough the hassle of reconfiguring and relearning something that is already working? imho it's not that much of a hassle

I've been working on [Elpaca](https://www.github.com/progfolio/elpaca) as a replacement for straight.el for almost a year now. The experience installing packages is IMO an improvement over straight.el.

I switched from el-get to Borg and Leaf. Borg is a pretty thin wrapper to just download the git repository, create an autoloads file, set up the load-path, and load the auto load file. Leaf is much like use-package but several defaults are reversed but it is much better than what I had been doing before.

If you have eglot without yasnippet, function completion would be without any parameters, which is a very big deal to me. lsp does them in their own way.

Thanks for sharing this looks like it will handle all the complaints I've had with trying to use emacs as a terminal application.

Basically fido is the icomplete-vertical with fuzzy selection and many bugs and edge cases taken taken care of. Vertico is a completion framework that is built on top of emacs's built in complete read and "definately does not wrap" it in functionalities to provide more functionalities and APIs.

Works fine for me in completing over 6500 files in a project. It never crashed or lagged on me. May be there is something that conflicts with it in your config.

How has been your experience with meow? Do you miss something from evil?

Even on emacs -Q it just "feels" less responsive, side to side. Maybe it's just my system.

> and any code written for standard Emacs completion will use them without any modification required Some modifications had to be done in Emacs itself, though

> Many "already working" solve-everything packages are brittle in the long term I've been using Ivy for 6 years (so it's 2 or 3 major releases), and still haven't experienced that brittleness. When do I expect it to happen?

> They can then reduce the number of external packages. But do they need to?

I switched from `ido` (didn't like the UX) to `ivy` not because it was new or something, but mainly because `helm` was too slow on my machine those days, besides that, I didn't like the idea of using external buffers for minibuffer completion.

> (elpaca-use-package evil :demand t) is there a reason to write wrappers for `use-package`, instead of just adding a custom dispatch keyword for `use-package` itself?

I switch to meow too, compare to evil, it’s lighter and faster, and would have a more vanilla eMacs experience. But there are two things I miss evil most: 1. jump to line/buffer start/end is not as convenient as evil 2. repeat command n times

Thank you!

>Once maintenance slows or stops Maybe you missed this part? It looks like Ivy has had >25 commits this year, so still quite vibrant. Let's hope it stays that way. Please don't take this as criticism. I have an older package myself that was a standalone island, and haven't had the time or need to maintain it. No new maintainers stepped up, so it slowly decays in place. What often seems to happen is standalone "big idea" packages, because they are unconstrained by Emacs APIs and built-in functionality, pave new ground and develop new capabilities and interfaces ideas, and then some of these are recycled into builtin and leaner builtin-adjacent packages down the road. Shoulders of giants.

They want to, and that's enough!

Yes. Elpaca installs package asynchronously. In order to do this and properly build a dependency tree, packages are queued prior to installation. Sans use-package a user's init file will look something like: ;;bootstrapping code omitted (elpaca 'some-package) ; this is only queued at this point. With the queue being processed at the end of the init file. I have a [branch](https://github.com/progfolio/elpaca/tree/feat/use-package-support) which implements a custom use-package keyword, but in practice the wrapping macro works better. The main issue is that the use-package macro will be expanded priror to it being modified. e.g. ;;bootstrapping snippet omitted (elpaca 'use-package (elpaca-use-package-mode)) (use-package oops) ; The elpaca queue has not been processed at this point. There are several ways I one could work around this. One would be a function which temporarily blocked until the queue has been processed: (elpaca 'use-package (elpaca-use-package-mode)) (elpaca-wait) ;our theoretical blocking mechanism (use-package example :elpaca (example :host github :repo "user/example")) I've experimented with several forms of such a function (polling via accept-process-output and sit-for). They're all unreliable. It works some of the time, or it can hang indefinitely. I suspect the polling interval has something to do with this and it would not be adequate to expect users to deal with that. It also defeats the purpose of designing things asynchronously. Long story short, the wrapping macro, which expands to: (elpaca example (use-package example)) is simple and works. If you're interested in more detail, there is this [issue](https://github.com/progfolio/elpaca/issues/7).

In my case, I am not even using Vertico or Marginalia etc. For me minimalism means, adapting to the way the Emacs authors propose we work. When I started with Emacs (2016), I added a ton of packages to make it look and work like VS. Then over time I realized I wasn't using that many of those features that I thought my editor "needed". And after that round of stripping down, eventually, I figured, "what more can I remove?". And it's been fun, and interesting. And challenging my conceptions of what I **need** and how I edit code 15+ years into my career is a nice exercise.

> because they are unconstrained by Emacs APIs and built-in functionality Actually, ivy is built on Emacs API and built-in functionality as well, and the new kids on the block had to make changes into the core in order to be able to advertise themselves as "more compatible ones". > and then some of these are recycled into builtin I see no reason to care if something is a builtin or not. If it works better and easier to use - it's better, otherwise - it's not.

You can search this subreddit for \`howm\`. I like it because all I do in org-mode is take random notes at work and it is much much smaller than org. Also I get to user markdown. Which while inferior to org's markup, it is used in more places :shrug:

Why should they? And could this be a reason Emacs is less popular than a dozen of counterparts these days? As a person who uses Emacs as a working tool, I would prefer 1 robust package over 10 half-baked ones, an external package with 10 dependencies over an internal one without deps, if the former works better and easier to use.

Funnily, this is the variable that started me in my "second wave" of removing external packages that I mentioned in another comment. Keep in mind this gives you only search matches, compared to anzu's replace preview.

well, how about `:after`?

I don't see how that would help. That controls the load order of features.

An example of how you can order elisp code

Thanks. I'm aware of how `:after`/ `eval-after-load` work. Unfortunately, they will not help in the situation I described.

I love the name. I’m happy to check it out. Reading the follow on comments one of the things I do like about straight is it’s integration with use-package which is how I try to structure my init file for new packages.

I try to replace `helm` by `fido-vertical-mode`. It works fine for `M-x` and `C-x C-f` and even for most `completing-read` stuff like `C-h o` But it lacks suitable replacements for `helm-occur`, `helm-descbinds`, `helm-describe-modes`, and probably some other nice helm-adons I don't even know about.