Hello everyone !
<tl;dr>
New bee fallen in love with kakoune. Not just for the visual, also for the simpler vocabulary and multi cursors.
I contend that multi cursors are a higher level, more declarative approach to text editing than the existing alternatives.
I placed the most interesting takes at the end with an example, so I folded the rest.
</tl;dr>
I’ve discovered kakoune for about a month now and have been using it for about three weeks. It’s the first non GUI code editor which I use, the only one which really clicked, and I must say I love it. Here is my beginner’s journey seeking a better code editor, and comparing options.
A bit of personal context
linux
I’m your stereotypical smart-ash computer science student who excel in science but cannot computer. I do love computers and have been using them a lot and from a young age, for games obviously, but also some fancy excel, fancy algorithms, fancy latex… But it took me a good 8 to 10 years of repeated exposure to Linux to be able (and willing to learn) to do anything more than ls and cd on a terminal. I’m the kind of guy who thrived doing Google Code Jam back when we only had to copy paste i/o using any language of our choice, including esoteric, but couldn’t get a hello world to compile when they started running solution on their server.
As far as text editor go, I started out using whatever free IDE for a given language looked superficially appealing, judging mostly the default highlight themes. I also edited in a couple plain text editors, like notepad and gedit, including but not only for bespoke languages which don’t have any IDE or LSP support. I really didn’t gave much thought to it and didn’t spend that much time coding either, baring maybe Latex.
In my last year of study, I had to teach “tools for the developer”. Linux, shell, bash, you name it. I was a fraud. To be fair, it’s hard to justify linux and its whole environment, let alone modal editors, to people most familiar with Windows who don’t spend that much time tinkering on a computer. Heck ! A good chunk, if not most software engineers don’t feel the need to use Linux daily (and in a lot of cases, don’t even have the opportunity to use it on their pre-installed, closely monitored, company provided machine). There were a few who didn’t really need a course, and there were the others, me the teacher included, who didn’t really need linux.
visual studio
Yet the same year, at a different entity, I also taught C++ and C# on Visual Studio. I spent a full day getting the free version to work on my personal computer. I’m not aware of a student managing this feat and make use of the licenses the school provided. A good chunk of the first 2 or 3 weeks was spent teaching Visual Studio specifics and shortcuts:
We would create a project,
we would choose console application among a dozen different types of project,
we would save it,
compile and run it,
and voilà ! it prints “Hello World”
The pupils would proceed to send me the VS project file. That file that describes the structure of the project and doesn’t contain any part of the code.
Meanwhile, I wrote all my code for this course in nano and compiled and executed it from the terminal. I would only ever touch VS during the classes, in order to have the minimal understanding necessary to cover the VS specific material and answer questions.
So while I was very clueless about proper work environment, I knew I wasn’t especially the most enthusiastic IDE enjoyer either. If nothing else, I liked about linux and shell the simplicity of copy pasting a single command to install or run a program. I grew spite for Microsoft typical bloatware, which, too often, even failed at hiding complexity inside the guts of a do-it-all application.
Notepad++
One year later, late 2022, I stray away from research and into he software engineering world. I land in one of these many above mentioned companies with very (de)limited responsibilities, outsourced IT, and a fetish for Windows. Most people use notepad++. Whether by lack of time or interest, they aren’t very mindful of their tools.
I received a training on config files using funcName. Funcname is an outline plugin for notepad++. It’s also a depreciated plugin. It’s been replaced by the more aptly but very differently named “outline” built-in feature. I’s been deprecated for 10 years. Doesn’t work on 64bit.
It took me 2 days figuring out funcName was outline and the training virtual machine was ten years older than my work machine.
For her defense, she’s on the functional side, she’s not a technical. More egregious is the absolutely amazing homemade bespoke IDE they made, that seldom anybody have been using for a good year after its stable release. Then again, most people had been waiting to have time locked on their calendar for a training. For one of the GUI tools which delivers on the promise of familiarity and discoverability.
In the same time frame, I start coding a lot on my free time (with job hop in mind), and become more and more cognizant about my environment, code editor and tool-chain. Which led me to VSCode.
It felt lazy at the time, still does, but it suited my needs for a simple environment to work on a project, without having to give it thoughts or time.
VS-Code
VS-Code is amazing.
It’s portable, it’s familiar, it’s discoverable, it’s trivial to shop for plugins, and it doesn’t shy away from having an integrated terminal. I don’t have, for each file type, to swim through 10 menus to setup an handful of commands with obscure environment variable to be executed when pressing F5-7. I can if that’s my kink, but I can also type compilation and running commands directly in the terminal, from within VS-Code.
And it has multi-cursors ! And macro? I guess?
Really, VSCode + LSP + a bajllion shortcuts is almost as powerful as vim based DE.
Sure more bloated and slower for sizeable projects, and a bit slower for the user to express their thought. But not that much. By a factor of 2 at most. It’s a feat to recon given the difference in accessibility.
The glaring issue is the bajillion shortcuts though.
Yes technically they are discoverable. They even have a whole tools to search through shortcuts, and one through settings, both are excellent.
But the defaults for all but some of the most basic things are garbage, some are internally inconsistent, some are inconsistent with other software convention, including Microsoft’s, some change drastically across OS for no apparent reason…
The most egregious thing for me to do in VSCode is focus switching. There is one different arcane shortcut for each different thing you want to focus to, a lot of the panels themselves are poorly navigable without a mouse, the terminal has its own keybindings which are a messy blend of terminal and VSCode keybindings…
At some point, why waste time learning longcuts for rigid action and poor composability when you could use fewer, more composable, some handscripted shortcuts? Somewhere down deep enough the VSCode rabbit hole, the investment becomes just as high as for the most elitist code editors, for tiny marginal returns, and no justification other than sunken cost.
Amazing nonetheless, but not a tool I do not want to master. A tool I do want to not master. I already know more than I wish I did.
Emacs
It’s actually my first contact with linux, learning OCaml in freshman year. I’ve tried to get into it on a couple different occasions, notably after seeing my advisor casually perform some dark magic with it, and for the appeal of fully customability, but to no avail. I’d probably use it again if I have to use OCaml again, or any interactive programming language, it does seem awesome conceptually, and especially fitting for some tasks.
But for now, I’m in no need of a lisp (over)powered OS.
In my very ignorant experience of Emacs, I’d say what put me off is the shortcuts again. They feel just as numerous and arcane as in a typical MS application, but with poorer discoverability. Maybe it’s just me, maybe there’s actually some logic in how the mod keys are used and how the sequence of key presses compose, which make it all easier to remember.
But it evades me.
Baring some very often used functionalities which didn’t fit in the keybinds space, anything needing 2 key presses with modifiers or more, I’d rather compose several other functionalities or fuzzy type a command for that.
Vim/nvim
I tried my hand at nvim a week or two before trying out kakoune. Vim tutor is awesome, pedagogical, and really provides a tantalizing glimpse at Vim’s powers. Besides, lua is my language of heart.
For lack of better reference, it feels like kakoune with a blindfold on. Well, less than kakoune, but that’s for later. If not for kakoune, I could definitely see myself spending the time and effort to learner nvim, but the process would be very tedious.
Kakoune
Kakoune is my cat’s nickname. That alone was reason enough to give it a go.
Accessibility
Trampoline is very indigent compared to vimtutor. And yet, be it because Kakoune is simpler, gives more visual feedback, is more discoverable, or maybe also because I did vimtutor and got familiar with the motion beforehand, nvim felt more alien after vimtutor than kakoune felt after trampoline. From what I’ve read and felt, this is a more general trend : Vim has an impressive, interconnected documentation which you can learn to browse blazingly fast. Whereas Kakoune doesn’t has much documentation, but also doesn’t have as much of a need for one either.
Doc still is a weak point of kakoune. I’ve found two cheat sheets which were of great help, the vimgolfs also provide great examples to go further, but information is hard to gather and sometimes outdated. Hopefully joining this forum will help me greatly as well.
Kakoune runs in a shell, it is modal, so it can’t compete with GUI, but in my book, the cost of getting into it is still significantly lower than for other modal editors.
Discoverability
Clippy is a banger.
I would even go so far as to say that, for someone not rebutted by commands, kakoune is a serious contender to typical GUIs as far as discoverability goes. The issue with graphical menu is the same as with "short"cuts : it’s great to have a few, but when you start having many menus and sub-menus, it becomes cluttered. At this point, fuzzy searching commands becomes more suitable.
And where VSCode or Emacs sometimes provides you with a greyed out shortcut besides the action, Kakoune provides the command description and usage. And because it’s a command it’s more powerful than any single button.
Vim and Emacs aren’t even close. (maybe I can’t read the doc lol).
A big modulation though, because kakoune is much smaller, it’s much harder to find answers to one’s questions through search engines, and LLMs will even give erroneous answer applying to vim.
orthogonality
I love it, it’s canonical, frugal, powerful. In practice, relying more on shell hurts the absolute accessibility and discoverability of kakoune, but getting familiar your shell ranks probably higher on one’s todo list than using a modal editor, so a fair evaluation of kakoune should take it for granted.
I love lua, but I love language diversity in general, and kakoune supports all languages for scripting more than it supports none. So another win.
Helix
I’ve considered Helix for a more ready-Out-Of-the-Box experience, and there are definitely some circumstances in which I would favor it ; but currently I work at a (new) place where VSCode is the standard, so if anything, I’d rather have a hack-able toy than a second OOB editor.
fewer idioms
A strong argument vim aficionados make against inverting the verb object logic, is the pending object argument. Kakoune has a single normal mode which must cram motions, selections, and verbs. In contrast, Vim’s normal mode only has to handle motions and verbs, and each verb may enter kind of its own selection mini-mod. A key pressed when describing an object may depend on the verb which triggered the prompting of that object. In particular, keys used for other verbs or themselves in normal mode can be freely reused in object selection. In practice, it means that kakoune copes with a much more saturated keybinding space by feasting on modifier keys.
I posit this is actually a strength of Kakoune.
In kakoune, there is no (need for) abomination like gg or dd. This is the kind of idioms of a natural language which feels smooth to native speaker, but feels weirder in a text editing language and puts off foreigners (well it put me off). In kakoune’s default bindings, there are way less instances of a key having two different meanings in different contexts. And for the most part, the modifier keys fit very well into composability (the same mod key tend to modify similar keys in a similar way).
I can easily imagine most native vim users are put off by the abundance of modifiers keys, and probably rightfully so, as switching to kakoune would likely only slow them down. However, as a newcomer, having fewer idioms is very valuable. And not just as a newcomer, I find it a lot more interesting to master composition than learning hundreds of idioms.
multi selection makes kakoune a higher level editing language.
A good share of vim aficionados don’t see the point of multi selection, and argue it’s just a different flavor of doing the same things, and that macro are more powerful anyway. If only that, it’s a better flavor already.
But let’s see a example (in Rust), written in part with multi-cursors, a mockup of a tiny edit I had to do in my current job:
match e {
MyError::Variant1(f) => warn!("this is a warning!", f),
MyError::Variant2(a, b) => warn!("Errorr of type 2 encountered with arguments {} and {}", a, b),
MyError::Variant3(Some(info)) => warn!("processing failed : wrong tidbits: {}", info),
MyError::Variant3(None) => if necessary {
warn!("processing failed : wrong tidbits: {}", info)
} else {
info!("no more stuff to do the thing.")
}
MyError::Variant4() => error!("4, the error 4"),
_ => panics!("unexpected error"),
}
println!("blabla.txt successfully processed");
Let’s say we want to make it so each of the message start with a uppercase letter within the error match.
In VSCode, you would, consciously and not:
- iteratively scan, with your eyes, for the begining of each message
- see if it starts with a lowercase
- make a mental note of which letter it is
- slowly reach out to your mouse
- once you’ve reached it, grab it
- move it to the character to replace and select it
- replace it with its specific uppercase variant
- manually repeat until all messages are treated, hoping you didn’t miss any
In vim, I guess you would :
- start a macro
- goto the next exclamation mark
- goto the next word or two
- change it to upper case with a single key command not specific to the letter to replace
- end the macro
- 5<macro> as you are smart, there are 4 variants plus 1 default case plus 1 variant which has 2 messages, minus one for the change you already made.
- start compilation and go make a coffe.
- come back to see the compilation failed despite you only edited print only string literals
- feel dumb after seeing the f in the first variant capitalized because of the exclamation mark within quotes
- undo to redo because your macro is almost good and you’re not a VSCode pedestrian, so you’re not gonna not automate a change you can automate
- you’re still smart so before undo, you look at the end of the match to see if there are other
!within strings without having to read the whole match, relying on your count of 5 replacements; it’s useless, as you gain no info from variant4 starting its message with a digit - So you rerun your macro manually, skipping the first exclamation mark manually, and checking the result of each macro execution manually, mentally coping by arguing that movement based vision is quick.
- hopefully, you didn’t fat-fingered and capitalized “blabla.txt” which you weren’t supposed to.
In Kakoune I would :
- select the whole match:
f{}}orf{]} - select all the exclamation marks:
s! - view that it is not enough, and match, for example:
!\s*\(or!\( - move to the next word or two:
wl - capitalize:
~
In this example, we see that kakoune multi cursor-approach, compared to a macro :
- allows to catch error early
- looks about on paar in user time with an error free macro
- is much simpler to come up with
- is more robust, using
s, we can confine our changes.
And I don’t even want to think about what a regex replacement would be like to uppercase part of a match (but kakoune has them, and can pipe sed, awk, … when it really is the best tool).
A big point I would like to make: simplicity and robustness in kak’s multi-cursors approach comes from reasons much deeper than just visual feedback.
Conceptually, my vim solution is the same as my VSCode pedestrian solution. Without a mouse and with a modicum of automation. But we still go through, iteratively, each place to make an edit.
Which means beforehand, we had to translate, in our mind, our elaborate declarative problem, into dumb, procedural steps.
Kakoune’s multi cursor approach is conceptually very different. We can almost directly translate our elaborate problem into kakoune language. In particular, “within the error match” becomes f{}}s in kakoune. It is completely lost when translated in macros.
Hence my affirmation : multi selection makes kakoune a higher level editing language than vim.
And that’s one of the many things I love about kakoune.
