But having to use the mouse for everything just drives me nuts. It's easier for my fingers to acquire even Emacs keybindings than it is for me to acquire the mouse and point at something with any precision.
As for key binding, it’s pretty easy to add that as external tools, thanks to the 9p interface.
however I still think acme is a conflagration of confusion. It has programs, inside of it, it's a text editor, a terminal, but breaks the interface of /dev/draw so it doesn't properly multiplex by rio.
Often stated, and I imagine to be true, acme was to be a full replacement for rio almost, but it ends up falling short of that.
What I'd probably most appreciate in Acme is a shortcut equivalent to / in vi, for those situations where I can see a bit of text I want to get to and it'd just be faster to hit (hypothetically) Ctrl-J and type a few characters vs grabbing the mouse. But I don't miss it often enough to go hacking the source :)
Up and down can't work, because acme was designed for proportional fonts, and many of us acme users use proportional fonts. Up and down are not well defined/not useful with proportional fonts.
I think that says a lot about the fundamental power of dynamic languages in general and Lisp in particular. Plan 9 is in a lot of ways the zenith (or … heh … acme) of what C and Unix can do. It is awesome, it is wonderful, it is better in every technical way than Linux or true Unix. But it pales in comparison to the hacked-together incomplete Lisp machine that is Emacs.
Imagine how much better off we would be with true Lisp machines on our desks and in our data centres!
(in my ideal world this 21st-century Lisp machine would actually take a lot of ideas from Plan 9, and even some from Emacs)
That's what Oberon, Smalltalk and even Emacs Lisp have that's not as good in Unix. Files full of plain text plus executables are a good foundation, but they're also quite unstructured and so is communication between them. Command line parameter parsing is an absolute nightmare. Whereas if you use a language directly, that's just function parameters and you're also not restricted to arrays of strings as your sole communication format.
Not that Emacs is doing all that it can with that, as it's usually used as an intermediary between a high-falutin' language environment and text files.
No way, acme is just ONE direction for Unix and C. Vi is another direction, as well as a ton of other editors that were made for Unix and C.
That evidence of keys being faster than the mouse are old?
Why would the speed change over time? It's measuring the human, not the machines; and we are no faster.
I've been using Acme for about 15 years now, though. I dimly remember deep frustration when I was still learning it, but now that I'm used to it it's great.
Here's a screenshot that shows my typical work layout, although it's a little "manufactured" to avoid including any proprietary code from work: https://i.imgur.com/Trg79NS.png
I’d enjoy seeing these parallel workflows happening, and seeing where Acme is a better <xyz>, or where it punts and has a completely different paradigm, besting your coworker (and vice versa).
Does the lack of "native" support for real-time linting, debuggers, formatters, etc get in your way? Did you manage to integrate such features in your workflow?
Here's a sample workflow: I'm hacking on some code in /home/john/foo. I have a directory window open in /home/john/foo, plus the files foo.go and foo_test.go open. I make some changes in foo.go, then in the directory window I type `go test`, select it with the mouse, and middle-click. This runs `go test`, creating an "Errors" output frame in the rightmost column. If the tests pass, this frame just says "PASS". If the tests fail, it'll say something like `./foo.go:27:10: undefined: xyz`. I right-click on `./foo.go:27:10` and Acme immediately takes me to that like in the appropriate file. I make a change, execute "Put", and then middle-click `go test` again to try the tests once more.
The delve debugger also prints line numbers that work with Acme. I run delve in an Acme terminal, and when I e.g. print a backtrace, I can simply right-click any of the line numbers to jump immediately to that code (Acme will open the file in question if it's not already open).
acmego will run gofmt and automatically add/remove imports as necessary every time you save the file, which is a huge convenience.
There's no syntax highlighting, which is a huge dealbreaker for some people. Personally, I find it distracting to watch huge swathes of my file change colors because I typed ", then change back as soon as I close with another ", so the lack of highlighting is great for me.
Edit: in my sample workflow above, I mentioned typing `go test` right in the directory window, but that's just ephemeral... you'll lose the commands if you refresh the file list, etc. A more permanent thing is to drop useful commands into a "guide" file in that directory; that way you can keep a whole suite of commands to run tests, run benchmarks, build & deploy, etc. right at your fingertips.
Edit 2: There's also a number of Language Server Protocol clients for Acme (see https://news.ycombinator.com/item?id=23782439 and https://github.com/fhs/acme-lsp) but I don't use them... I'm old-fashioned.
Some that stuck out were using filenames plus regexes or line numbers to create links in text files, a text file that is also a shell session, things that have been done in vi/emacs but this editor is mouse-centric so it looks very different.
I would add to your list:
- acme is complemented by the plumber, which acts according to user defined rules when receiving a text selection (and context)
- anything in acme is text, which is editable. Menu bar, buffers, shell window... the editable dumb terminal is great.
- acme features a 9p fs "api" to access its state, and modify it, with any program. Go is first class citizen.
Acme cannot be used though ssh in a terminal nor on a iPad though :)
Sure vim is a vastly superior text editor and acme is a better "integrating" text environment. Something as different as a Jupyter notebook.
As for vim limits: poor mouse support, window management, plumber support, notebook like features (emacs org Babel), editable interface, jump to /path/to/file:/search pattern/ and other Sam expressions ...
