Why Kakoune

Recently I’ve stumbled upon a video about Kakoune, a code editor: Idiot user tries to use Kakoune (for notes? Also Helix?). Funnily enough, I was mentioned in this video, which was a surprise, and made me laugh for quite a while:

Let’s go back to the official plugins page. This guy has made a bunch of plugins. Who is he? How is he able to make such good use of Kakoune? Oh, he’s an Emacs user! Of course!

Yeah, I am.

Even though the video is about Kakoune, the author’s main focus is note-taking and the oddities that come with this process when using a code editor to edit text. Kakoune advertises itself as a code editor for the most part, and I have to agree. As far as I know, Maxime Coste (@mawww), the creator of Kakoune, made it because of the desire for a better programming experience. As a result, a small and contained code editor was made. And I can appreciate a desire of the system one can fully grasp and understand.

Kakoune is relatively small, compared to Emacs and Vim that is. It doesn’t feature a scripting language, instead relying on shelling out if you need any programmable features. It’s a clever trick, and the editor exposes its internal state as a set of shell variables, so you still can do interactive things based on your workflow. And I did a lot of this back in the day when I used Kakoune.

I have mentioned Kakoune in this blog previously, but it was rather sparse. The reason for that is stated in the video pretty accurately - I use Emacs and not Kakoune, so there’s little to no reason for me to write about it besides occasional praise or comparisons. I mention it on my about page, and in various text-editor-related posts, but that’s it. I don’t participate in the Kakoune community anymore, and no longer actively maintain my packages, as I no longer use Kakoune.

But I still need to address this point of the video - I wasn’t an Emacs user when I started with Kakoune. Before Kakoune I was a Vim user! And transition from Vim to Kakoune was caused by several factors, one of which is again stated in the video:

…and people have written so many damn Vim plugins over the years that if you have a need it’s already been addressed like three or four different ways. So with Vim you could just piece together your ideal text editor like LEGO bricks…

And that’s exactly my problem with Vim - too many ways to do the same thing. At the time, I was working with SoC in C and started using the Ale plugin for asynchronous linting of the project, as the synchronous linting was quite slow. This was before LSP inception - just look at how many tools Ale supports. As far as I remember LSP was added to Ale much later, when competing plugins showed up.

Competing plugins.

There’s nothing bad with competition on its own, and in Emacs, this is also present, with many plugins, but in Vim’s case, I feel that people created most of the plugins purely because of the NIH¹ syndrome. I lost count of how many plugins provided autocomplete interfaces, there were tons of list-narrowing frameworks, plugin managers, and snippet managers, and everything was poorly integrated with each other. I remember that some autocomplete plugins did not integrate well or at all with snippets, some synchronous completion providers were not supported by asynchronous completion frameworks, and so on. Again, this was before LSP came to the scene and basically became a standard for these features. So perhaps the situation is a bit better today, but I still have doubts. NeoVim people are going crazy over Lua API, writing their configs in Fennel, and making new Lua-based plugins that may or may not be compatible with the rest of the ecosystem.

Fact is, you can piece your dream text editor like LEGO bricks, just beware that some of these bricks are actually Duplo blocks, some are COBI bricks, lots and lots are probably LELE, and some are even freakin’ OLEG. Well, at least that was the situation when I used Vim, I gave up on updating my config around 2018 and made the switch to Kakoune. By that time I already made three plugins for Vim because I was unsatisfied with existing ones, but they were crappy too. Integrating these plugins into different other plugins was a huge pain. So I made the switch. You can trace the history from that point if you’re interested in my Kakoune journey (why would you be though).

Obviously, I missed a lot of features from Vim, and Kakoune actually has an entry on their wiki on how to migrate from Vim. Unfortunately, though, the suggestions were either too hardcore-minimalist or uncooperative. For example, Vim’s smarttab feature didn’t exist, and expandtab was suggested to be done via hooks. Not that it was wrong, but it was suggested when people asked about a very specific feature of Vim, and these did not provide the same feature as in Vim. So I started writing plugins.

However, Kakoune didn’t have conventional plugins at all at that time. Well, there was a section with plugins on the official page, but there was no real ecosystem. There was nothing such as Vimplug if you will.

Installing plugins meant you had to manually copy files around, or load them pathogen-style, but the process wasn’t convenient or easy to automate in my opinion. Updating plugins installed in this way was problematic too. This motivated me to make plug.kak. And then I started experimenting more and more with other interesting plugins.

But, around the same time I switched to Kakoune, I briefly tried Emacs. In reality, I tried Emacs like 4 times at that point, the earliest one dates back to around 2010. All four times I did not succeed, but something gravitated me to it for some reason. This last one actually was a reason why I made some plugins like langmap.kak or kaktree, which resemble what I saw in Emacs at that point. Many plugins were inspired by Vim, like smarttab.kak, powerline.kak, fzf.kak, tagbar.kak, equivalents to which I daily used in Vim before. And at that time, Kakoune really did everything I needed and was a very capable code editor.

But I still wanted something more. So why I made the switch to Emacs - but for a bit different reasons.

First of all, I started enjoying writing more prose instead of just writing code. And if you’ve watched the video I linked above, the author similarly wants a text editor, not a code editor. There’s another video on their channel about note-taking, featuring a lot of programs made specifically for this task, and it features a text editor section at the end in which the author talks about Emacs and Vim, briefly touching Kakoune and Helix. What they’re saying about Emacs is also very similar to what I’ve experienced, although I didn’t use an Emacs distribution, I started with vanilla².

Org Mode.

I don’t know how to explain this to a non-Emacs, non-Org person, but every time someone asks the “Why Emacs?” question, Org Mode is somewhere at the top of the answers. And I never understood that, until I tried for myself. And boy are they right. But before I understood that, there was a long period of adoption. I still used Kakoune, but more and more I was shifted towards Emacs - it slowly consumed me.

A big part of that was that I started writing in Lisps. Emacs is the king when it comes to Lisp editing. Plugins for various Schemes, that I used to do tasks from the SICP book were amazing, and Kakoune :repl command paled in comparison. Though I can’t blame anyone here - Emacs is a lisp machine on its own, it’s bound to have great lisp editing experience.

Though lisp wasn’t my primary language back then, more like a novelty. I used Rust and considered switching jobs from a C engineer to a Rust back-end developer. Rust seemed both a perspective and a safe enough bet for the foreseeable future. Who knew how the tables would turn?!

Kakoune actually was great as a Rust IDE of sorts. The kak-lsp plugin was on it, written in Rust it supported Rust well. And it helped me at work with C too. That was 2019, the year I started using Emacs for real.

That year, I made my first, kinda big post, in which I realized that I wanted to write more. Ironically, it was a post about Emacs on the Kakoune forum. It was even written partly in Emacs and partly in Kakoune - I was comparing editors at that time, much like the author of already mentioned videos. But this day signified that I was ready to fully migrate to Emacs - my config was more or less ready for work at that point. Emacs seemed better at writing, although I was missing cool Kakoune features, such as multiple selections, a lot. I started writing this blog in 2020, and it was done in Emacs from the get-go. Not so long after that, I moved to Emacs completely.

I used Kakoune for 1.9835616438356165 years (first commit on Jul 24 2018, last commit on Jul 17 2020).

But this post actually is called “Why Kakoune” and not “Why I switched to Emacs”, so let’s address that!

Why Kakoune

What an awfully long preamble. If you read that, you have my thanks. If not - fair enough.

I think it’s kinda weird to read reasoning on why someone should use Kakoune from someone who’s not using Kakoune right now and hasn’t for another three years already. But, as far as I can see, not much has changed in Kakoune since! Which, actually, is great - I can actually just check out to a commit previous to the one I deleted my Kakoune config in the dotfiles repository, and run it. A fresh clone of Kakoune’s latest stable release builds in just two minutes on my machine, and loads my old configuration without too many errors:

At this point of the post I wanted to write about stability, but as it seems, the situation isn’t that great.

• Some plugins simply no longer exist.
• Some defaults were changed in 2022, making keys behave differently (can be turned back via a remap)
• Some changes were made to how Kakscript is interpreted.
• Most of my plugins broke (but that’s on me).
• There’s possibly more, but I’m out of the loop.

What’s hasn’t changed is that people still stumble on the autoload directory after all these years. Because there’s no plugin manager in Kakoune, it relies on storing scripts you want to load automatically during startup in the ~/.config/kak/autoload directory. This, however, for some weird reason, disables loading a system-wide Kakoune autoload directory, and Kakoune simply stops loading all of its inbuilt features that are shipped as .kak files. I also experienced this problem, and it was one of the main reasons for making plug.kak. So, if anything above seems too weird, perhaps Kakoune is not for you.

But, given all that, Kakoune hasn’t changed that drastically over the three years I haven’t used it, and that’s a good thing. Even now, I can still edit files in it pretty comfortably after my brain does the switch from Emacs keybindings to a modal model. For the most part, that is, some habits are hard.

But one thing, that I think can be a main reason why people should try Kakoune, in my opinion, is its POSIX integration. Back in the day, I really liked this idea, can’t say so today³, but, it’s still a good reason why Kakoune is interesting.

I mentioned that I made plugins for Kakoune, and because of that I now know POSIX sh pretty well. Not that I need this knowledge that often, but when I do, I’m glad Kakoune taught me well. The same goes for other POSIX tools - Kakoune basically forces you to learn your shell stuff, because there’s no other way to be productive in Kakoune. Everything is done via shelling out to use some tool like fmt, grep, find, etc.

And when shell tools are not enough you can always call different programming languages from the shell. For example, some of my plugins are written in Perl of all languages. And while I can’t say that I’m proud of that, or that I know Perl that well, I can still say that Kakoune made me learn Perl, well, to some degree. Also, Awk. And I still occasionally use both when I need to send a code snippet to my colleague so that they can send me some filtered logs instead of full logs. Because that’s what these tools excel at, and learning how to use them from within an editor really makes it apparent how they can be useful. So Kakoune really helps you learn your standard tools, and some extra things too.

Another thing I think can be said is that Kakoune really makes you learn and understand regular expressions. When I started using Kakoune, I once told my friend that I started using an editor that is built around using regular expressions for text manipulation. They were quite skeptical, because I didn’t know regular expressions back then, and they had some experience and said that it’s a terrible idea to use them at all. But turns out, that regular expressions are actually easy to learn, and Kakoune really helps with that, because you’re constantly creating multiple selections, selections in selections, and filtering selections - all done with regexes. So, if you think that regexes are hard and you’ll never learn them (and you’re a Vim user by chance), give Kakoune a try.

And finally, Kakoune is just fun! Especially if you’re a seasoned Vim user, the inverted paradigm of object-verb really messes with your brain. I think Kakoune features a really unique editing model, where it doesn’t need any separate mode for selecting text - all motions do it automatically. When I started, I adjusted to the object verb paradigm pretty quickly, it’s very natural to how things are done - in real life, we usually don’t think upfront what we want to clean and then how many of what was that, ah yeah the shelves. We think that these shelves are dusty and we need to clean them. I should probably do it right now.

Anyway, a TL;DR for this could as well have been:

Kakoune gives you:

• Small and understandable core.
• Proficiency with POSIX tools,
  • and maybe even some programming languages other than sh.
• Structural regular expressions as a central way of text manipulation.
  • With multiple selections created via regular expressions, acting upon regular expressions.
• Fresh take on the modal editing paradigm.

So, yeah, Kakoune definitively deserves your attention, if you’re into experiments with your workflow. I, certainly, am. At least, I was, now I do everything from Emacs.