A Tour of Acme (2012) [video]
research.swtch.com
research.swtch.com
More acme info at http://acme.cat-v.org
Acme has a cousin, sam: http://sam.cat-v.org
http://www.vitanuova.com/inferno/index.html
Anyone trying Plan 9 ideas is missing out not trying its last iteration.
If you look at some of the white papers, Pike starts with assertions that the mouse must be a front and center input mechanism. I reject the premise.
I'd argue pushing as much functionality to the keyboard and using natural language to interact is more productive in the long run.
It was a popular idea at the time. In fact, Acme is a clone of the user interface of Oberon OS. The difference (from the Mac) was, while the mouse as designed by Apple had only one button, Oberon and Acme required three buttons and the user's ability to press some of them simultaneously (termed "chords").
While I find the Plan 9's (and Inferno's) window system elegant and useful, with the need to be able to use the mouse pervasively and in such an intricate way, these OS and editors seem to have jumped the shark.
It is a personal thing, but I have always been more productive that way.
I'd suspect we spend more time processing what we are going to do than we do actually doing it. I often find myself pausing to think about how to get the right layout I want in i3, but if I just could drag some windows around, it'd be done.
The mouse is very intuitive, that's probably why Jobs got stuck on it. It's hard to get much more "natural language" than literally using text to control actions as Acme does.
Similarly, using a pen is a clear win for artists, which is why wacom and now surface are such successes in their fields.
Starcraft players on the other hand perform a task where one hand can always stay on the mouse while the other is on the keyboard.
Spacemacs and the Hydra package for Emacs are interesting as well but I actually prefer to just start typing commands until I get the match I want.
But I while the mouse is dangerous (due to rsi) and limiting (five fingers become 1 to 3ish buttons) - I don't think the keyboard is the best we can do either.
I actually think the direction Ms is taking with surface and wheel is very interesting.
And for a while, I've believed an acme inspired (multi)touch&pen interface is likely to be a good way to take user interaction a step further.
- files and command line sessions are both just windows. You can split, move them, and EDIT (including output from CLI commands) anything you want. This feels much more natural than having a dedicated run section in the editor or using a separate terminal (that obviously can't be split next to a file window).
- a really short list of commands it supports (very little to memorize). But since it's so easy to interact with acme through the filesystem, you can easily customize your own workflow. For example I wrote https://github.com/mjibson/aw which is a web interface to Go's guru. But there are at least 2 other acme interfaces to guru, both with different methods of interaction, depending on what the author preferred. Overall I like this a lot more than memorizing a pile of vi shortcut keys.
- manipulating text is pretty fast with the mouse + acme's chords and the esc key.
- right click to search or go to file:line is much more powerful than you expect.
Tmux can do that pretty easily!
- tmux mouse support gets better every release, so you can actually select, send or exec, there is no chording though. - vim has remote features, so you don't need multiple vim instances. Yoy can "send" to a running vim instance. Vim splits are pretty powerful, buffers being independent. - neovim has :term support too, i would not recommend it
Acme found a nice usability sweet spot, mixing an editor with shell and a tiling wm. Tmux and vim can imitate some interesting behaviour such as 3-click to open, but the general behaviour isn't as consistent.
A search for Plan9Port brought up the Github page for me.
1. https://groups.google.com/forum/#!topic/plan9port-dev/OqSvUD...