Edit: A text-editor mixing vi and Acme
c9x.me
c9x.me
I switched to Kakoune after trying to find something more Acme-like for the terminal. In fact, I still use all the scripts that I wrote for Acme. To insert the results of a command, you can use `! <command>`. To pipe, highlight and use `| <command>`.
You don't get mouse chording, but I find I don't miss it too much.
I've never used Kakoune, but reading about it I'm not sure it's an improvement.
One powerful vi feature is the dot command, and having verbs act on selections doesn't allow for that in the same way.
From the mastery standpoint, Kakoune seems like a big step down from the vi model. Too many of its commands/selections seemed to give priority to the edge case over the central one. Most of the text editing I've ever done with vi is of the garden-variety "navigate to this line and insert/delete/change one thing". Kakoune makes this more difficult by creating multiple cursors/selections as a side effect of its movement/navigation tools. It's like Kakoune is trying to tell me "no, you want to edit stuff all over the place!"
I also think the promise of Kakoune, that you can use selections to see what will happen before you type the command to actually make the change, is violated when there are selections outside of the visible portion of the file. Furthermore, with vi/vim I tend to type commands so quickly that the visual nature of Kakoune would only slow me down, and so at that point the advantage of selections is greatly diminished.
Then I switched to neovim and got :set inccommand, which visually shows you the replacement as you type it, which feels like it accomplishes what multiple cursors/multiple selections is trying for
Regarding the worry of visual distraction of selections slowing down editing, I found the opposite to be the case as I became more fluent with Kakoune. Motions modify the selection, and it is quite common for the selection to serendipitously contain what I want to modify. Constantly visible selection(s) lead me to implicitly take advantage of motion and use fewer keystrokes.
Regarding multiple selections outside the visible window, you are right that there's no visual feedback for those selections, which is a degraded experience compared to when all selections are visible. But that's no worse than the experience of a global search/replace in vim. You are arguing that in an edge case, Kakoune is no better than vim, which doesn't seem like a meaningful detraction.
This is going to be a dealbreaker because having things moving around in one's peripheral vision is extremely distracting for a lot of people, including me. When I am typing I want my focus to be on the one place where I'm inserting text. I don't want to see all these other cursors moving around.
But that's no worse than the experience of a global search/replace in vim
I rarely ever use the default global search/replace in vim. Most of the time I search with / and then perform an edit there, and then use n.n.n.nn.nnn. to repeat the changes in the places I want.
But there are a couple of things that just don't work for me and my brain can't make it work. Multi-select is one -- it seems to me to be a fringe case that I rarely use, but it is core to kak and causes confusion every time I need to <space> out of that mode.
The other is the fact that the cursor is always on a character (rather than admitting an "end-of-line" state is a distinct state), combined with the fact that a non-select "mode" is not a mode at all, but is a one-character selection. While I admit that this is more uniform, it means that the behavior of "delete the current line" is odd; "xd" will (select the current line) and (delete it). But if the line is blank then this won't work, because x will advance the selection (since the current line is already implicitly selected as a one-character end-of-line selection) to the next line.
I like the plugin model, but I think that relying on tmux for the splitting will eventually be a liability that we'll need to unwind in favor of a native splitting mechanic. The Vim project drawer model is too powerful to rely on unreliable interactions with an independent system.
http://doc.cat-v.org/bell_labs/sam_lang_tutorial/sam_tut.pdf
I admire Vis but at the end of the day a text editor is just a tool. When the investment into changing out such a tool becomes worth it is entirely user dependent.
[1] https://github.com/martanne/vis#non-goals
[2] https://github.com/martanne/vis/wiki/Differences-from-Vi(m)
http://acme.cat-v.org/_imgs/obsd_acme.png
Though a screen shot really can't sum up what makes acme so wonderful. Try Russ Cox's A Tour of the Acme Editor:
I prefer a Go clone of Acme, edwood, albeit it's damn slow if you build the plan9port-less port without SSSE3.
Edit: He mentions it's been updated since the video to use multiple actual windows.
It would be incredibly unfortunate to sacrifice the ability to become more like Acme by shooting yourself in the foot and making it terminal-based, and anyone really in the market for acme with vi characteristics or vice versa probably would realize why the paradigm doesn't work in a purely-TUI manner.
IIIRC there is a web implementation too but last time I tried it it didn't work. YMMV
Most people want a typewriter interface because they want/need to edit files in an ssh session on a remote server. Plan 9 doesn't do remote teletype control and instead imports/exports resources. Of course plan 9 has ssh but it is split into three separate programs: an ssh client that performs the regular teletype interface to a unix machine, sshnet which imports the remote systems tcp stack, and sshfs which mounts a remote file tree locally.
If I wanted to edit text files on a remote unix machine, I'd just mount the file tree locally using sshfs and run sam or acme locally. Bring the resources to you and use your local tool set. Then you don't have to worry if the remote machine has x installed because you don't care.