Why Kakoune – The quest for a better code editor
kakoune.org
kakoune.org
But a typical editing session will go through a lot of "invalid" states by design. Trying to enforce that structure is preserved at all times is a hindrance in many scenarios.
And further, if you bake structure into your editor in that way, it's much harder for anyone to invent new structures. Having good tools for unstructured text editing is valuable as, if nothing else, a fallback for when your structured editor doesn't understand the language you're editing.
My understanding is that tools like Eclipse and Resharper work on pretty similar models internally to prevent complete failure to understand a code file while it is being mangled by the user.
So you need the text-based fallback here, and you still need it anyway for the case of editing something a structure the editor doesn't know.
Does anyone know how Kakoune does in terms of these features? They're all much more important to me than say, syntax highlighting, which I find neither here nor there.
Cross-file grepping, and fancy fuzzy finders are considered beyond the scope of the editor, but the wiki has some tips for integrating a separate fuzzy finder program into kakoune [2].
Emmet would be super easy to implement but it just hasn't been yet to my knowledge.
They all have a steep learning curve and it seems like you need to climb pretty far up that curve before you can even judge if it is worth it to begin with.
Playing with it for a while did prompt me to look into and adopt vim visual mode, which I've never really used (was it even present if vi on ttys?). It's a step closer to the more rational (to me) 'selection, action' ordering.
I can install keybinds for it in any editor on the planet, there's at least a vi on any system I happen across, things like qutebrowser ships with vim bindings by default, etc. etc.
Also, how often do you use a brand-new clean system without any extra software installed? You might regularly do this if you're a sysadmin/devops person, but in that case, you ought to be using Ansible or something to bootstrap the machine to a robust state, and that would include customizing Vim if you rely on it heavily. The "quick edit to system config files" use case for Vim is also not the same as the "software development environment" use case. You can get by with unconfigured Vim in this scenario, but it doesn't obviate the need for a complete configuration if you plan to do intense editing later.
The fallacy that "Vim is everywhere" is perpetuated by people who don't use Vim for software development.
I started with a much bigger load of plugins than I use now, and I don't think I'm unusual in that. The stock settings and workflows, once you understand them, are usually better. The only exception is really for frills - like, a plugin that helps with composing regexes, or language-specific IDE stuff, or a pretty documentation browser.
Not to mention, it's really very quick to get all your normal plugins set up. I have a git repo that I just clone.
Eventually I found myself not adding key bindings because $random_server wasn’t gonna have those.
The problem is, vim is everywhere, and Kakoune isn't. :(
I want to switch but need to make the process a bit smoother.
It sounds like I should try Kakoune...
--
[0] - C-s z RET C-w, if you're not using transient-mark-mode, aka. a visually marked, explicit selection common to most editors. With transient-mark-mode disabled, there is always a region between mark and point, and after accepting a search with RET, C-s drops a mark at the place you were when you started the search. transient-mark-mode is active by default (probably to reduce learning curve); working without it is weird at first, but also rewarding in terms of efficiency.
Or just do . (full stop/period), which will repeat the last command, and in this case delete to the f you want.
Kakoune is kinda like vim in visual mode (or block visual) with multiple cursors.
My point wasn't that repetition is a panacea, but that the example in the article isn't a good one.
So the example given, dtf would become vtfd. That’s one extra key stroke but realistically if you can touch type you won’t notice. You can expand that selection with ; for the next t.
Personally I’d use dtf and then just use undo if its not what I want. I’d also use dot repeat command, gcf or a visual column to act on multiple selections.
Use / to first select what you want to change. Then use cgn to make a change and . to repeat it. n will skip a change.
This still might not be exactly what you want and that’s fine. It’s always good to try new ideas and new software but for me vim gives me plenty of options already.
"Modal editor · Faster as in less keystrokes · Multiple selections · Orthogonal design"
I love it when software developers assume everybody else knows what their software runs on. SMH.