Andrey's "Why Kakoune"

This post made it to hackernews a while ago: Why Kakoune · Andrey Listopadov
One insight that resonates with me is that Kakoune encourages and facilitates learning (regex, Unix tools and concepts). Learning standard tools (instead of large APIs of other editors) can be a big boon. I think this “why” is not immediately obvious to new users

9 Likes

I used emacs for 4-5 years, before switching to kak a few weeks ago.
I used EXWM, the emacs x-window manager. I.e., emacs was my desktop environment, and would manage my web browser as well as terminals and text files that I was editing.
I loved how integrated it was, I didn’t want one set of hotkeys to switch between the browser, terminal, and text editor, another for tmux tabs, and yet another for files in the editor. I also didn’t want these to be segregated; switching between them should be relatively free.

The unix philosophy is normally stated as being about individual tools mean to do one thing, do them well, and be able to integrate with others.
For a system that works well and is easy to extend, the important thing is to have modular software components with clear APIs.
The level at which this occurs isn’t so important – write source calling functions, emacs packages working with one another, or separate processes on a posix system, or something else.

I got impatient with emac’s performance. Note it is single threaded, and not especially concurrent.
The language server (eglot) supposedly tries to do things concurrently, but in practice it regularly introduced pauses.
The fact that I write a lot of Julia for work also could make this very frustrating – calling the formatter or using the Julia language server are great ways of introducing random pauses, whether because of JIT latency or Julia sometimes just being incredibly slow.
But even Clangd (which is vastly more capable than the Julia language server) could sometimes add lag.

Also, all the Emacs terminals are slow (vterm and eat are way slower than the likes of foot, alacritty, wezterm).
E.g., there was a package that displayed a progress meter for fitting a Bayesian data analysis, and the rapid incremental updates/redrawing it would do would bog all of emacs down!

Finally, I figured I should just try something else. Moving away from EXWM would get rid of enough of the appeal, that I figured I should just try something else.
At first I tried helix, but after reading phaazon.net I realized with some work, I could replicate most of what I liked about my previous workflow: a window manager (now a non-emacs tiling WM) managing different windows each connected to the same kak-server.

Kak’s emphasis on being a unix system trade’s emacs integrated system (assuming you live inside it) of elisp packages (which admittedly often shell out to rg and friends) with the unix system.
Plus, I find C/C++/Rust more readable and writeable than elisp, anyway. On top of being many times faster than JITed elisp.

5 Likes

Overall, Emacs is probably the greatest environment there is. However when considering simple use cases, it can appear too big and complex.

Before 2018 I used Vim, Emacs and Spacemacs. I also had some performance problems; Magit was noticeably slower than Tig on large repositories. Spacemacs also felt generally sluggish.

I didn’t dare to try to fix Spacemacs for my use cases; either I’d have to look into some of the hundreds of plugins; or worse, it could have been a problem in the C core.

Having been spoiled by Spacemacs I wouldn’t want to go back to Vim. I feel like I’d have to tinker with a bunch of plugins to get a comparable experience - not an enjoyable outlook; I don’t have much appetite for learning obscure configuration switches, especially if they are not here to stay.

I want my (rather simple) use cases to work well. I also tried Emacs from scratch but it seems much easier to get productive with the more modern Kakoune. For any missing feature, Kakoune has a small but powerful API relying on Unix tools, so it’s way easier to extend as well.
In a way, Emacs shelters you from the messy outside world but it can be better to take the plunge…

4 Likes

I found Andrey’s blog a while ago looking at fennel and it took me a minute to realize it was the same Andrey who made a couple kak plugins I used to use. felt like a small world.

I’m hardly a poweruser of anything really, I mostly just mess with scheme and GLSL, but I love to tinker. I tried Vim and Emacs(several times actually) but I enjoyed modal editing and Kakoune’s paradigm made more sense to me than Vim’s, so that’s what I stuck with. Tinkering and how much I enjoy scheme and common lisp keeps me thinking about Emacs for obvious reasons, but at the end of the day every time I give it a week of my time I come away feeling like it’s not worth the effort because it does waaay more than I want or need to do. Kakoune fits in my niche real nice, is really fast and enjoyable to use, and had the unexpected side effect of teaching me to work with POSIX tools better as the blog post mentions. It also gives me just enough rope to mess with little things here and there to satisfy my need for that. I don’t think it’s fair to compare it to something like emacs or even vim at this point, sure they all can edit text but really the scope of kak compared to the other two are quite different(even though you can technically drastically expand the scope of kak which is neat).

side note, andrey has a new blog post about shelling out, vterms, etc and emacs and its interesting.

2 Likes

Comments on this Hackernews thread : foo editor, bar editor, baz editor, random Dvorak subthread…

It’s all so tiresome.jpg

I’ll throw in my 2 cents, as it’s been awhile.

I use Emacs and Kakoune, but at work at do use VS Codium for our front-end stuff.

Emacs has a lot of great bits in it that I love, but from a programming perspective it’s quite a headache to configure. This probably to do with the nightmare that software development has become over the years, and just Emacs having a massively broad scope in general. Eglot and LSP-Mode are at the whim/mercy of the LSP server’s implementation, it could be great or it could be a still long work-in-progress. Same with anything related to tree-sitter. Maybe I’d have to do more investigation, as I put aside configuring Emacs to actually get work done, but maybe Emacs is geting there to where it can replace everything I use for work.

Kakoune has it’s great bits, too, but I’ve just used Emacs so much that I’m just used to Emacs more. Kakoune is great when I use it, but Emacs has Org-Mode and I don’t think any external implementation of Org-Mode in some other editor will ever match up with Emacs.

I hope kakoune continues to succeed, as I personally think it has a better base than Vim/Neovim.