If you want the ability to pipe commands more natively, Kakoune does that. It also improves on vi's commands syntax, and allows multiple selections.
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 am always trying to see if I can switch over to Kakoune -- I love the fact that the syntax is more uniform.
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.
I have used Kakoune. I tried it out pretty extensively for a few weeks. I could not get comfortable with it. I've used vi and vim for two decades now. Kakoune seems like it would appeal to people who have moderate exposure to vi/vim but not mastery.
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.
Counterpoint: I have used Kakoune for a year now, immediately following sixteen years of heavy vim use. I find Kakoune far more intuitive than vim, because the feature set composes so well. Within the first few weeks I understood the command set well enough to combine features to solve editing problems I would have had to look up solutions to if using vim.
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.
visual distraction of selections slowing down editing
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.
I used to use multiple cursors in sublime before i switched to vim, and 99% of the time the thing i wanted to accomplish with multiple cursors could be done easily with :s/pattern/replacement/ or some variant of that.
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
I've tried out vis and it's very nice editor. I'd love to see something like vim-slime developed for it so it could be used for repl-based development. I may even get off my lazy a-- one day and try to implement it myself.
Structural regular expressions seem pretty great. If Vis ever gets some Vim features that allow operating across multiple buffers (quickfix et al) I'd probably switch.
That would cover some of my wants but not all of them. Whilst I like the idea of structural regular expressions they're not a big enough of a motivation for me add anything I'd miss to Vis when Vim is "good enough". That said I'm less and less impressed with Vim as time goes on so that will likely change at some point.
I think that's the biggest challenge for a project like this. If it's going to break backward compatibility, it's hard to attract new users even if it's clearly an improvement over vim. Ironically, that was the whole issue with Plan9. It was better, just not a big enough improvement to justify replacing something that was widely viewed as "good enough".
I mean it's a separate project so it has nothing to break "compatibility" with and it's made clear [1][2] the aim is to be different. Given the author is part of the suckless community I really don't think they care about attracting users either.
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.
Fair enough. I wasn't posting that as a criticism. I'm a big fan of suckless tools, dwm, st, and surf in particular (I may be the only person who likes surf), and I truly hope vis succeeds and is around for the long term. I'm hoping vis can attract enough users to develop enough of an extension ecosystem that it could be used in place of vim or neovim as a daily driver
The killer feature of acme (and, previously, sam) are structural regular expressions. As far as I see (and I admit I did not take a deep look), this is more a simple vi-like editor that runs inside an acme-like window manager.
Even though a few people hinted this had to do with Plan 9, I had to look up that Acme refers to a window-system, shell, and editor environment. Here's a link to save you a search if you're in the same boat:
Acme is inherently graphical. Moving to a terminal application would be a regression, in this particular case. Then again, X11 is also a regression, in Acme's case.
Watching the video, this "Edit" editor does look like could work in a terminal. The split screens that come up don't look much different than what you see with tmux, for example.
Edit: He mentions it's been updated since the video to use multiple actual windows.
Acme doesn't work in a terminal. Acme is a window manager that can edit text, use multiple fonts simultaneously, revolves around the mouse and has near-perfect synchronicity with the underlying system. Edit's long-term goals list is more or less "become more like Acme."[1]
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.
Works also on other graphical systems. Acme itself talks the plan9 graphical protocol which. There is an implementation of that protocol in the plan9 from userspace port (https://9fans.github.io/plan9port/man/man1/devdraw.html). I'm using it on macos where it's a native application with retina support and native macos fonts, native macos clipboard etc.
IIIRC there is a web implementation too but last time I tried it it didn't work. YMMV
Plan 9 abandoned the ancient concept of the typewriter interface and instead uses a graphical 2d engine called devdraw. With that you can mix and match text with graphics in the same window. We emulate typewriter interfaces in the vt program which is a graphical program that implements a vt terminal. Its 2021, use graphics.
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.
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.