Does anyone use this daily? this gets posted a few times a year to HN but tbh it looks like someone just re-invented vi. Which seems kindof like creating a new religion. It can be done, but even the best televangelist isn't going to hold a candle to the spread of the catholic church.
I've gone for several week long stretches of using it but never fully converted. What winds up happening is that I get to a point in a project where I really need to focus on the code and not the editor, switch back to vim, and don't get around to switching back for another few months. The editing model is better than Vim's and if I didn't have 20 years of vim muscle memory I probably would have switched over by now.
I disagree that the editing model is better than vim. It’s fancier and makes for flashier demos but I don’t think it’s better. For one thing, it places the emphasis on editing in the large. That is, its default operating mode is to leave multiple cursors all over the buffer when you’re trying to jump around your file. You have to build a habit of pressing an extra key to dismiss the multiple cursors so you don’t inadvertently start inserting text in multiple places without realizing it. This is the wrong approach!
Vim puts primary emphasis on quickly getting around and making small edits one at a time. Editing in the large can be accomplished easily with the substitute ex command or search and repeat (via n and .) or macros recorded with q. For any programmer, the vast majority of their time is going to be spent editing in one place at a time. When they need to do something bigger, vim has them covered. If they’re finding they need to do some more sophisticated refactoring they probably want an IDE (or at least an LSP plug-in for vim of which there are many).
> That is, its default operating mode is to leave multiple cursors all over the buffer when you’re trying to jump around your file.
That's not true, motion commands don't create new selections. Search will create a new selection only if you explicitly ask for that by pressing shift N.
You can do the Vim approach just fine, and I usually do. I write prose in kak for goodness' sake, I don't usually have multiple cursors for that. The only time I accidentally get extra selections, besides old muscle memory triggering that feature in search with shift-N, is when I accidentally click in the terminal, which was going to mess me up with any editor.
But occasionally it's very nice to actually have that multiple selection feature. For instance, suppose you have a search and replace that you only want to do on certain instances of your search, in a context dependent way. You could just use n and . repeatedly. However, I find it nicer to examine each selection, drop the inappropriate ones individually, recheck my work, then do all the edits at once. This also eliminates (granted, by defining it away) the problem of changing your mind halfway through the search process about what change you want to make. When you change your mind, your cursor is either still live in all the places, or you're done, in which case at least there's only one thing to search for again, not the half that were changed and the half you hadn't reached yet.
> is when I accidentally click in the terminal, which was going to mess me up with any editor.
Well, most terminal editors don’t capture the mouse at all — this is what I personally prefer (let the terminal emulator handle it) and as a bonus it fixes this problem.
When I last looked at Kakoune, it struck me as “Vim with training wheels,” in the best sense of the term. In other words, it has (all of?) vim’s keyboard commands, but with more visual feedback to show what they are doing live. I envisioned myself learning with Kakoune and eventually migrating to vim once they became ingrained. Or, at the very least, becoming proficient in vim so that I could use it more confidently when needed.
Editing in Kakoune encourages and enforces a different editing style (one based on visual selection).
You'd have to still learn Vim.
Personally, I played https://vim-adventures.com/ to get a basic grip on Vim, later I kept a cheat sheet handy, and yet later I just looked up commands and features as necessary.
I recommend disabling the arrow keys in your vim config and to just use it.
I've been using Kakoune as my daily driver for almost a year. The thing that made me fall in love was the simplicity, both in daily usage and in extensibility.
The biggest "oh wow" moment for me was how easy it was to create a color scheme. In Vim, creating your own color scheme is potentially a huge ordeal, with many edge cases. For example, vim-one's color scheme file is over 800 lines long.
By contrast, I created a fully functional Kakoune color scheme in only 84 lines, 60 lines if I remove extraneous spacing and comments. There is no conditional logic, no legacy support, just one set of standard "faces" that work everywhere. All languages use the same standard set of faces to do their syntax highlighting. The difference that makes is astounding.
This is but one example of Kakoune's orthogonality and simplicity of design. Coming from Vim, which is chock full of legacy code and an inconsistent mess of configuration, it's a breath of fresh air.
I would have thought that creating/adapting a colour scheme is a onetime activity when you start using the editor for your language. Do you update the colour scheme regularly?
I used color schemes as an example, perhaps it was a bad one. I don't update it regularly, no.
As others have said, the appeal of Kak is orthogonality and accessibility. The keybindings are sensibly organized, there is exhaustive autocomplete and on screen documentation, and the configuration language is simple. It is ridiculously easy to write plugins for, because you can use shell scripting, or create a program in any language you want and invoke it from a shell block. Kakoune's LSP plugin is written in Rust and communicates with Kak via the shell.
Sorry if it looks like I was being flippant. I wasn't. I had some colleagues in the past that did adjust their colour scheme almost monthly. I think it was when syntax highlight first came onto the scene back in the mid 90s.
Oh you're fine! I didn't think you were being flippant. I've been using One Darker (One Dark with a darker background) for two years and don't have any plans to change anytime soon. Here's the source for the theme if you're interested. It has gotten a little bit more complex than I described in my post, due to supporting various plugins, but it's still pretty easy to understand.
I am using it daily, as my sole editor, for a little more than a year now. Before that I used Neovim. Most important reasons for the switch are:
* Leaves window management to the window manager, so it works much better with a tiling wm. I wish all applications did this.
* Selecting first and then specifying an action works way better than the other way around, as it is done in the Vim family.
Edit: regarding the comments and Vim's visual mode, you are right. I like to change my second bullet to "Does not have too many modes, like the Vim family."
> * Selecting first and then specifying an action works way better than the other way around, as it is done in the Vim family.
There is visual mode in vim too you know. That's for doing exactly what you describe. I use that when I'm unsure about the movement I need for an action.
That's exactly what I used to say before I tried kak. I had been using vim for about 6 years and thought it sounded like vim with multi select and wasn't impressed.
The reality is, you change the way you think about editing. It took about a week away from vim but eventually I could see the selections in realtime. Not as a gimmick like with multicursor vim, but as the basis of everything. I have been using it exclusively for 2 years and haven't looked back once. Single-cursor editing is about the same speed, but selection oriented editing blows vim out of the water with anything with 2 or more edits.
It's like if a notepad user said "what's the point of vim? I can just use a mouse and arrow keys??" Vim changes the way you see things - you see a space separated word so you use W or a line with whitespace at the beginning so you use I. It's hard to explain other than you change your understanding of editing.
Edit: that gimmick comment might annoy some people. I used to use it and love it. But the reality is, it was just an add-on to an already-grest editor. After my plugin phase of vim, I realised it didn't really add much at all. So 'gimmick' is probably too harsh
Vim has all the tools necessary to achieve the same end result with the same convenience. [0]
Just thinking about what crazy things I've done with macros that multi-cursor would be incapable of handling makes me chuckle.
vim doesn't need the fancy features of other editors (except for maybe LSP and tree-sitter for a more IDE-like experience).
The core problem is that you don't grok vi [1] which is fine, not everyone has time and passion for that. But please don't think for a moment that vim is inferior just because it doesn't blindly copy other editors features.
Judging by https://github.com/mawww/golf kakoune is capable of completing the majority of the same editing tasks as vim in a very similar amount of keystrokes. The main advantage of multiple selections is that you can see which text you will operate on ahead of time, rather than having to first select which operation you want (delete/yank/change/etc) and then which text it will affect. I think pointing out that vim's selections aren't as capable as kakoune's is a fair response, and saying that you can accomplish similar things without selections is a bit of a deflection.
Golfing is not the best representation of day to day text editing, but I must say that optimal Kakoune solutions are usually pretty close to normal workflow.
Vim allows me the exact same thing using visual mode. even better, I can still use the powerful move commands in visual mode to control what is selected, before triggering an action on the selection.
I tried to use it enough to see if I could switch to it from (neo)vim. I liked a lot of the ideas in it, and in some ways I liked it more than vim, but it was missing some functionality that I just couldn't live without. Some things could be solved by plugins that just didn't exist yet, but others, I couldn't even see a way a plugin could be implemented. In particular, there isn't any way to get a diff mode comparable to vim's.
I also don't like that it always unconditionally writes a newline at the end of files. I understand the reasoning for it, but it makes it much more difficult to use as an editor for transformed binary files (gzip, hex editor, encrypted files, etc.) or avoid adding extra whitespace to git diffs when I modify files.
There's a few reasons I can think of (some superficial, some significant):
- Github and git will highlight a missing newline in a diff by default.
- POSIX defines a line as having a newline at the end, so if you don't have a terminating new line you may have one fewer lines than you think you have [1]
- If you ever want to append to a text file/source file programmatically with something like echo "something at the end" >> yourfile.txt then you'll be grateful you had the habit of ending everything with a newline.
- If you use a shell that doesn't automatically add one when you do cat filename you'll end up with your prompt sitting awkwardly at the end of the file.
vim, iirc, defaults to automatically adding a newline to any file without you explicitly asking for it, unless you do set noeol and set binary or, in versions newer than 7.4, set nofixendofline
> vim, iirc, defaults to automatically adding a newline to any file without you explicitly asking for it, unless you do set noeol and set binary or, in versions newer than 7.4, set nofixendofline
which, IMO, is the right way to do it. In kakoune however, it isn't just the default, there is no way to turn it off.
I just ran into an issue with that recently. The Pandas library for Python doesn't consume the last line of a CSV unless it's followed by a new line. I would say I couldn't believe that it actually made inject that newline if it wasn't in the input, but Pandas has enough other oddities that it was pretty easy to believe.
I've used it daily for ~6 months now. Before that I had used Vim for close to 8 years and tried many different editors during that time but I always went back to using it. I feel Kakoune truly is an improvement over Vim and I highly suggest you try it if you like modal editing.
At Symflower we do, one of us has it as its main editor and it looks extremely productive. As a former VIM hardcore user i enjoy the pair programming sessions. I guess these sessions must feel the same way when a non-VIM user watches a VIM hardcore user.
I use it daily for many years, being a user of vim for 20 years or so.
I could not come back to vim now, I find the kakoune way more efficient.
I find two annoying things :
- U need to make a lot of tuning to make it usable because there is now tab management, no clipboard, etc..
- U need always the last version of C++ compiler to make it compile. This is annoying on professional VMs that are way behind the current version of gcc.
I would suggest the community to make better documentation for plugin development which can be very hard to learn
I had the same problem building Kakoune on more elderly systems, and settled for building a static binary on my own machine that I could then run on shell accounts on other people's boxes if the toolchain isn't new enough to build in situ.
kak locates its runtime library relative to the binary path, so it works fine in ~/bin & ~/lib or ~/.local/bin & ~/.local/lib even if your home directory is different on different machines.
shameless plug for my tab manager plugin: https://github.com/enricozb/tabs.kak
disclaimer: I'm in the process of a decently sized refactor so the configuration instructions will soon be changed/outdated.
I used Vim for ~7 years, fully switched over to Kakoune a few years ago. My primary reasons are:
1. always selection-first focused
2. multi-cursor support combined with #1 is really intuitive
That's about it really. I have it set up primarily with User Modes, to avoid modifier keys as i don't like reaching for modifiers, and i'm pretty happy.
I've been using it as daily driver for 3+ years. I switched from Spacemacs.
Focus on selections, visual feedback and simple integration with other Unix tools are main differentiating features in comparison to vi family of editors.
I have used kakoune almost exclusively for two years. Prior to that I used vim for 16 years, emacs for 10 years before that. For me kakoune started as vim visual mode done right, but I have come to love the editor because it has a small orthogonal command interface that provides all the power I had with vim, but with lower cognitive burden.
Kakoune is a fantastic tool of rare quality. I find it a joy to use.
I tried it for a short time, but given the ubiquitousness of vi/vim, I just couldn't get myself to commit. I want to keep my muscle memory intact for when I have to ssh into a remote computer somewhere. Which, I guess what I'm saying is, it looks like I'll be attending mass this Sunday.
I've been using it for the better part of three years after using Vim for many years.
What I like about it that it is intuitive. Selections make sense. The visual feedback is great too. I've configured nearly nothing, the out of the box experience is great.
kak is my daily driver. About the only customization I do for it is the integration of fzf for file picking-- althought its window management with kitty seems to be broken, I have to run it inside tmux for this to work. Recently I more often than not use broot as the launcher for kak instead of directing kak to open files from inside kak.
Multiple selections with the visual preview before action was the key feature for me-- it is a nice affordance compared to having to mentally model what an operation would do with a vim movement.
That seems like a weird analogy. There are fabolously rich and successful American megachurch pastors (or whatever they are) that probably have no connections to the Catholic Church.
It replaced sublime text for me for scripting languages like PHP, bash and stuff. I still prefer VSCode for js/ts and native IDEs for compiled languages.
