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'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.
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.
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.
Has that been anyone’s experience?
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.
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.
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.
https://github.com/raiguard/one.kak/blob/main/colors/one-dar...
* 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."
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.
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.
[0] https://engagor.github.io/blog/2018/02/21/why-vim-doesnt-nee... [1] https://stackoverflow.com/a/1220118
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.
Both of which neovim has.
Agree with your premise, though: (n)vim does not need multi-cursor selection, for the reasons have given.
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.
- 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
[1] https://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1...
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.
> echo hello > hello
> echo -n hello > hellon
> wc hello hellon
1 1 6 hello
0 1 5 hellon
1 2 11 totalWe even have an extension for Symflower https://github.com/symflower/symflower-kakoune that is how much we appreciate Kakoune.
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
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.
Get binary PKGSRC packages from Joyent and set PATH accordinly.
https://pkgsrc.joyent.com/install-on-linux/
It's for RHEL and clones but it should work on any parallel distro or more recent.
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.
Kakoune is a fantastic tool of rare quality. I find it a joy to use.
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.
I'm never switching back to Vim.
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.
I love it.