I've taken a month or two off from plugging Kakoune on HN because I was worried about becoming tiresome, but I can't resist mentioning it in this context. I used vim for 20 years, although I always preferred to stick with the default configuration. I switched to kak a couple of months ago, and I couldn't be happier. It's got great tmux integration, it automatically runs a server so you can connect multiple clients to one buffer, and it has a novel selection-oriented modal interface that's not just an attempt to mimic Vim.
I think Kakoune is particularly interesting here because it integrates window splitting using tmux and a client-server model instead of re-implementing it which is what vim does. This is part of Kakoune's design philosophy: to be composable with other unix tools. Other examples of this are file browsing[1] and fuzzy finding[2] using ranger and fzf, or even just piping a selection to `fmt` to reformat a paragraph.
I wish someone would build a VSCode-like shell around kak, in order to provide a good IDE experience. I keep thinking it should be possible using Qt, with plugins providing a GUI part in the form of a QML widget that gets embedded in the GUI, and possibly a daemon component that gets started and managed automatically by the shell. So e.g. you'd have a file browser widget on the left showing recently opened files etc. that spawns new tabs or opens existing ones when you click on the files. But you could also instead have a project widget or whatever. Basically I want someone to make a pluggable IDE, with a focus on adding graphical widgets for the purpose of richer interaction than plain terminal allows, but lighter and easier to extend than Eclipse, one which focuses on integrating with a specific editing component, in this case kak.
I'd like to try Kak, a friend recently told me about it. But, I'm concerned about needing to relearn common commands. For instance, I believe that they mentioned that in Kak the Vim equivalent to `dw` is `wd`. I've got decades of use with Vi(m) under my belt, as well, and I am not too thrilled at the idea of having to unlearn/relearn common commands.
The whole point of Kak is that it's a different editing paradigm, still modal and "text editing language" based, but in subject verb order rather than verb subject order. The idea is to give you more confidence as you type your commands by visually showing what they'll be applied to, instead of having to wait to see the result if you screw up.
If you're not interested in kak because of that paradigm change why are you interested in it at all?
Having switched to Kak recently, I've found this painful since I sometimes SSH into machines with only vi installed and so have to switch back and forth between kak and vi; it's a real headache...and a real shame since kak's selection method is much nicer IMO
I find that I get irritated at vi / vim for not being as nice as kak, but vi is still useable. The hjkl keys still work, :w, :q! and so on are still the same. I, i, O, o, P, and p still do the same thing. Basic movement is almost the same except you don't get selection with your movements. I tend to fall back on this common subset when I'm using vi. Marks are different in kak, so I don't think to use those in vi. Same thing with ex commands. I'm more likely to use sed rather than messing around with vi's ex commands now.
The thing that confuses me most since the switch is vim's visual selection mode. I used to be a really heavy user of visual selection mode (V and v), but since selection is at the core of what kak does, vim's way of doing it seems really clunky now.
If I'm going to be spending more than half an hour on a machine, I'll probably end up taking a minute to build kak on it.
If I can SSH to a remote host I can use Emacs TRAMP mode to edit files or I can mount the remote machine file system with SSHFS and change the file locally.
It's painful, but on the plus side it's way outside of the uncanny valley, it's not like a vim clone. In practice I found that this meant going back to vim (kak didn't work for me) easy.
