This is really cool. Any plans to design one specificaly catered to programmers?
I am not the creator, but I’ve found that MadRabbit has something like rockstar-layout: “In an essence this is a variation on the QGMLWY layout from the carpalx project”. I don’t think it’s ai-powered though.
Not OP but I have created a programmer-centric keyboard layout for MacOS that might be interesting to someone.
What is the motivation for this editor? It’s not clear why I would choose this over anything else, especially when many programming environments support Emacs/vim style interaction.
You can read the justification here. Largely it is based on the idea of switching commands from vim’s verb-object pattern to an object-verb pattern, which enables the useful behavior of showing the user what they’re modifying before they modify it.
Combined with some other useful features like multiple selections, and a client-server model like neovim, I have to admit it’s pretty appealing to me. I’ve been a vim user for about 20 years, however, and it would likely take quite a lot of retraining to switch now. Edit: Not to mention the fact that no official Windows support is planned; I prefer to use the same editor on all operating systems if possible.
I was a Vim user for 20 years, and after using Kakoune for two or three weeks I started finding Vim frustrating and clumsy. That’s partially because Kakoune’s more orthogonal keymap makes Vim’s x and v redundant, so it replaces them with other commands, but also because of Kakoune’s movement-is-selection model. In Vim, to delete a word, I hit w until I reach the end of it (but not past it!) and then db to delete it, or sometimes bdw if I haven’t had my coffee yet. In Kakoune, I hit w until it’s highlighted, and then d.
Wait, in vim, why don’t you do it the other way around, use w to go the beginning and then dw? Or daw (delete, around, word) if you’re inside a word?
Oops! It’s been so long since I used Vim that I forgot wworks differently there.
This is something i have explored when trying out versor-mode for Emacs. I had no idea Kakoune did the same thing. It’s a very powerful paradigm to start treating editor navigation as a coordinate system for various dimensions of a text file.
In versor-mode, these coordinate axes are an explicit modal choice, but setting it implicitly based on the last navigation command sounds highly useful.
As Vim moves more towards the Emacs model of “Do it all inside” (following Neovim’s lead), I became less inclined to buy into this model. So the thing that really made me look at Kakoune isn’t what it did – but what the author insists it shall NOT do. From giving window control over to like i3/tmux/$X to delegating to the shell – I think this approach has value, and I think it will continue to benefit from this core decision.
The low-level documentation on using the API or internals are well done but information on use cases is lacking. However, there are some interesting tricks in the code. In particular I thought making the main struct a union of either a heap or stack object was interesting. This comes with some tradeoffs like wasting space if you have lots of strings smaller than RS_STACK_CAPACITY and you don’t know just by looking if you’re dealing with a struct or a pointer. The latter seems like it could lead to leaks or ownership confusion unless one is very careful.
That’s the “small string optimization” and is completely standard in C++, though not used (for example) in Rust. As you say, it has lots of tradeoffs. Generally Rust code is written in a way that minimizes excess allocation and copying, so it’s reasonable. As you say, that requires very careful tracking of ownership, which is of course Rust’s strong point. It’s of course possible to do the same in C, but very easy to get things (subtly) wrong, much more so if there’s sharing across threads.