brhfl.com

I’m not writing this post in vim, which is really a rather odd concept for me. I’ve written quite a bit about vim in the past; it has been my most faithful writing companion for many years now. Part of the reason is its portability and POSIX inclusion – it (or its predecessor, vi) is likely already on a given system I’m using, and if it isn’t, I can get it there easily enough. But just as important is the fact that it’s a modal editor, where text manipulation is handled via its own grammar and not a collection of finger-twisting chords. There aren’t really many other modal editors out there, likely because of that first point – if you’re going to put the effort into learning such a thing, you may as well learn the one that’s on every system (and the one with thousands of user-created scripts, and the one where essentially any question imaginable is just a Google away…). So, I was a bit surprised when I learned about Kakoune, a modal editor that simply isn’t vim¹.

Now, I’ve actually written a couple of recent posts in Kakoune so that I could get a decent feel for it, but I have no intention of leaving vim. I don’t know that I would recommend people learn it over vim, for the reasons mentioned in the previous paragraph. Though if those things were inconsequential to a potential user, Kakoune has some very interesting design ideas that I think would be more approachable to a new user. Heck, it even has a Clippy:

~                                                          ╭──╮   ╭───┤nop├────╮
~                                                          │  │   │ do nothing │
~                                                          @  @  ╭╰────────────╯
~                                                          ││ ││ │
~                                                          ││ ││ ╯
~                                                          │╰─╯│
~                                                          ╰───╯
nop          unset-option                                                      █
:nop            content/post/2018-06/kakoune.md 17:1 [+] prompt - client0@[2968]

Here are a few of my takeaways:

• There’s no inbuilt window management/splitting, by design, which is something that I understand but do not like. The idea is that different sessions running in different X windows or tmux splits can communicate with each other, so the windowing burden is better left to these systems. This is fine, I guess, on my Linux box with i3. Less great on my Cygwin or Darwin terminals where I don’t particularly want to run a multiplexer just for a text editor. While I often have multiple splits open in vim to bounce content around, I do the rest of my multitasking via simple job control. Lack of windowing also makes it unsuitable for diffing.
• There’s no inbuilt file browser, which is also by design. This is technically true of vim also, netrw is a plugin, but it’s there by default. netrw is much-maligned, but when necessary I do like to be able to :e . and find my way around.
• Kakoune takes a very long time to start up (well, for a text editor), which is odd since the previous two design decisions are listed alongside the editor’s goal of being snappy.
• There’s no inbuilt spellcheck, which makes sense if you’re only targeting coders. But only targeting coders is kind of a dumb choice when minimalist editors are great for distraction-free prose writing, and formats like Markdown, Textile, and Fountain make WYSIWYG a regrettable memory.
• Normal mode is always a selection mode, essentially akin to Visual mode in vim. This is a real standout feature that both cleans up the number of modes (compared to vim), and simplifies the language and consequences of an action. In vim, I can make a guess at how many words I need to delete, aiming to under- instead of over-shoot, and end up doing something like 10dw 2dw, or I can step into Visual mode. In Kakoune, 10w automatically selects those ten words, and then 2W adds two more to the selection. I guess this seems trivial, but in practice I feel a lot more grounded as far as knowing what text I’m operating on. And this is after years of using vim. Moving around as normal (with hjkl) is still a selection, it’s just a selection of one character.
• The cursor doesn’t change when you switch between normal and insert modes, which may or may not be related to the previous point. Some people seem to think it is, but I don’t think anyone on the dev team has said as much, and it honestly makes no sense – the cursor being a block in normal mode suggests that operations happen on characters in normal mode; being a bar in insert mode suggests that you can’t be on a character, only before or after one. Anyway, I had no idea how much I relied on that until I kept getting mode-lost. Apparently it isn’t being fixed any time soon.
• Fortunately, changing the status bar’s color based on mode was not terribly tricky, handled via something Kakoune calls hooks, very similar to autocmds in vim. More awkward, in my opinion – every hook needs a filename regex, so in the case of changing part of the colorscheme based on mode, you have to drop in a pointless .*. At least the format of these commands is always the same, there’s no contextual change. It should also be just as easy to change the cursor color, partially mitigating the previous issue.
• In general, configurations are awkward just like the previous point. Much of this is justifiable – for instance, word-wrapping and line numbers aren’t normal options, they’re baked into ‘highlighters,’ which feels super weird coming from vim, but might make sense for some users who, say, want line numbers for code but not prose. I prefer consistency, and even wig out a bit when vim’s help behaves differently than my other files.
• Despite the awkwardness, making a colorscheme was fairly straightforward, which is good because defaults are kind of bonkers, and the default colors were not terribly serviceable. On the topic of defaults, I have yet to get Markdown highlighting to work. Everything is just a little bit fidgety. I’m going to play with it a bit more, but will probably post decolletage.kak at some point.
• Keybindings rely heavily on Alt instead of Ctrl, which… might be justifiable, because in a standard keyboard configuration, Alt is less awkward to chord than Ctrl. But it goes against all terminal standards, and people have ways of making Ctrl work (*cough* reassign Caps Lock *cough*). If the dev team wants any vim converts, replacing things like Ctrlo with Alt; is just a weird move.
• Documentation is severely lacking in comparison with vim, but there is one area that’s considerably better. Remember Clippy up there? There is a ton of inline help and guidance, which works great when you sort of know what you’re doing, but isn’t as helpful as far as discoverability.
• Multiple cursors are built in, and alongside the normal-is-always-selection-mode paradigm, it works really well. For a while I used vim-multiple-cursors, which is pretty impressive, but kind of felt like a crutch or a bad habit more than anything else. There was nearly always a native vim way to do what I was trying to accomplish. Kakoune’s multiple cursor system is a native solution, and much like the selection model, actually feels like its helping and guiding you.

I guess there are far more negative points in that list than positives, but the truth is that the positives are really positive. Kakoune has done an incredible job of changing vim paradigms in ways that actually make a lot of sense. It’s a more modern, accessible, streamlined approach to modal editing. Streamlining even justifies several of my complaints – certainly the lack of a file browser, and probably the lack of splitting fall squarely under the Unix philosophy of Do One Thing and Do It Well. I’m going to continue to try to grok Kakoune a bit better, because even in my vim-centric world, I can envision situations where the more direct (yet still modal) interaction model of Kakoune would be incredibly beneficial to my efficiency.