A Tour of Acme (2012) | Hacker News Reader

A Tour of Acme (2012)

research.swtch.com

95 pointsgklitt59 comments

I use Acme (from Plan9Port) as my every-day editor for work. I run it full-screen on a 4K monitor. I've got a co-worker who likes to grumble about mice, but somehow when we're debugging something on a call, I'm always in the appropriate file at the appropriate line number long before he is :) There are some tools (acmego [9fans.net/go/acme/acmego], A [github.com/davidrjenni/A]) that make working with Go a lot more pleasant, too.

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've been willing to try it for a while, now.

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?

Go tooling actually works surprisingly well in Acme, because the tools tend to print out files with line numbers for errors, then when you click on that line number Acme will take you directly to the line in question.

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.

One of the main argument for Acme was that keyboard navigation is tends to be one dimensional, whereas navigating with mouse is two dimensional.

I find it curious that a higher-than-one dimensional representation of a program is not present: proper syntax highlighting makes debugging much faster.

Say, I want to see some expression with deeply nested parenthesis (lisp-style, or nested function calling in Python) is matching. I can do that with my eyes, checking the color of the beginning and the ending parenthesis. Same goes for, say, if I want to find a string in my program. I don't have to care about the quotation mark, I can just look at its color being different from the rest.

Executing commands with the mouse is heavily underrated and is a behavior I fail to faithfully replicate in i3 - or even Emacs, for that matter - but only if you guys had syntax highlighting...

I consider the lack of highlighting part of a "calm" interface: the only thing that changes as I type, are the characters that I type. But maybe that's just Stockholm Syndrome after 15 years of Acme! :)

When I need to check nesting levels, I use a little acme-trick: double-click on the closing mark (works for parentheses, curly brackets, quotes, probably more) and it'll highlight everything contained within that level. So if I type (some (big (lisp (expression)))) and want to make sure I got the right number of parentheses at the end, I just double-click on the last one and make sure the whole expression gets highlighted. Here's a screenshot: https://i.imgur.com/Qyvv2K9.png

I don't find I need to do it particularly often when writing Go, though, and if I do... well, I start to think about refactoring to make my function invocation less obtuse, or whatever.

Interesting! But you see all of the benefits of syntax highlighting and real-time linting is about being steered towards a working code in a gradual and unmotivated way, prior to actually intending to check whether the code works... Although I'm not sure how critical this really is. My personal argument for them might really `only` be habit.

Regarding syntax highlighting, I created my own Emacs theme a few years ago to have only a few constructs highlighted:

* The name of a function being defined

* Comments

* String and character literals

The result is very calm [1], but I can still rely on colors to know orient myself and know when I forgot to close a string literal.

[1] https://vfoley.xyz/syntax-highlighting/purp3.png

> but somehow when we're debugging something on a call, I'm always in the appropriate file at the appropriate line number long before he is :)

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).

Another thing I forgot to mention: Acme can be controlled programmatically, and there are Go bindings, so I wrote my own little mpd client to play music while I worked. You can see it at the bottom of the leftmost column in the screenshot... looks like Blue Oyster Cult was playing when I took the shot. It wasn't a lot of code (https://github.com/floren/Ampd)

Perhaps this might sound like a noobish question but I found the video super cool. That said, does acme has syntax highlighting? I think with that I'd be willing to learn it.

No.

Acme is an incredible, fascinating editor... that relies too much on rat wrestling to be useful to me. I really find it interesting how it takes advantage of Plan 9's aggressive Unix philosophy to provide functionality that would've been plugins or extensions in other editors as separate C programs or scripts.

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.

It is definitely an interesting editor, and it has some neat ideas. But when I compare the masterpiece that is Acme on Plan 9 with the — frankly — cobbled-together heap that is Emacs … I would prefer to use Emacs, because Emacs does more for me than Acme on Plan 9.

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)

Have you had a look at Oberon? That's where Acme took most of its stuff from, and it being a fully integrated language, the interfaces between the parts are a lot cleaner.

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.

> Have you had a look at Oberon?

No, but it is on my list of things to look at when I get some free time. It sounds like another one of those tantalising might-have-beens.

One of my retirement projects will be to write an OS as it should be, given what we have learned from decades of research and use. I imagine that I will never complete it, but it will give me something to do with my time!

> is the acme of what C and Unix can do

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.

I was making a pun: 'acme' means the highest point.

But I also disagree with you: acme is strictly more powerful than vi, and vim is just a Greenspunned Emacs. Greenspun's Tenth Rule holds that 'any sufficiently complicated C or Fortran program contains an ad hoc, informally-specified, bug-ridden, slow implementation of half of Common Lisp'; I contend that vim is an ad-hoc, informally-specified[0], bad-taste (seriously, have you ever looked at Vimscript?) reimplementation of Emacs's functionality.

It does, however, have better keybindings than Emacs does by default.

0: outside of the POSIX stuff it gets from vi, that is

Emacs is built on Unix like vi and everything else. The fact that vi has a less elegant language doesn't affect me, because I don't see much value in adding extensions to the editor. What I need is a sane user interface, which vim provides.

The original Emacs was written for Multics at a time when people outside of Bell Labs were largely unaware of the existence of Unix[1]. It also doesn't follow the Unix philosophy of making small CLI utilities composed with pipes. As I understand it (though I haven't used it), Acme is extended with external programs which communicate through pipes just like the traditional Unix utilities.

[1]: https://www.jwz.org/doc/emacs-timeline.html

The first version of Emacs was not made in lisp, instead it used TECO, a horrible programming editor/programming language.

Sometimes it just feels faster to think about and execute keyboard shortcuts, although the actual tests I've read about that seem to be from the early Macintosh age, which feels a bit like measuring anything by looking at your university's students...

I don't understand what you're saying.

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 think speed could change over time because our generation uses computer and common shortcuts from childhood. People who participated in the study could have been much less experienced users at that time and the shortcuts might have been less established and more varying from platform to platform

That's an assumption that needs to be verified. Sure, over a generation it's quite unlikely that evolution made for better mouse users.

But we don't need to go that far. I mean, when you were testing during the development of the Mac, it was what, 1983? The mouse was a new thing, CUA didn't exist yet, I doubt that many vim and emacs users were part of the target group.

I doubt that speed changes if you test the same demographic as back then, although it's harder to find people as unaccustomed to mice.

In addition, has there ever been a test that includes mouse chords as used in Acme/Oberon?

It is convenient with a pointer or trackpad close to your thumb. Three buttons associated with such pointer or trackpad would be nice, but it would work much better with more buttons. Two or three buttons for each hand would be awesome.

I used acme for years with a laptop and no external mouse, just using the trackpad (and trackpoint). I never missed more buttons.

So currently control, option, and command are three buttons. I'm wondering if it would be better with the left and right sides functioning differently. You could get many more chording combinations.

Sorry, but a trackpad or TrackPoint just makes things worse. It's much harder to precision-highlight a chunk of text with those than with the mouse (or my Logitech TrackMan).

It would not be infuriating if basic movements were possible using the keyboard, such as the classic left-down-up-right.

As for key binding, it’s pretty easy to add that as external tools, thanks to the 9p interface.

Left and right already works.

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.

Up and down works just fine in just about every word processor out there, using proportional fonts.

> 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.

It can work with proportional fonts. Word for instance defines it well enough to be useful. Rather than down taking you to the same column on the next line, it just takes you to the character rendered at a similar x coordinate on the next line.

And this is useful when writing code how?

I'd use such a feature if I had to fill a table, and wanted to move to the same column on a different row. But with proportional fonts, the columns don't line up. So yes, it can move to the same x coordinate, but why is this useful?

> And this is useful when writing code how?

It's useful for general text navigation, and writing code is an instance of that.

> I'd use such a feature if I had to fill a table, and wanted to move to the same column on a different row. But with proportional fonts, the columns don't line up. So yes, it can move to the same x coordinate, but why is this useful?

"Doesn't work well for use case X" != "not useful [in general]"

If your text is laid out assuming fixed-width fonts, and it's important for you to move to the same column in a different row, then just use fixed-width fonts and the method I described would work as you expect.

Word processors use up/down keys to move up/down one line, at the same index, or the beginning or the end of the previous ‘ next line, if they exist. It can work.

Acme is opinionated and it’s a good thing if it fits its userbase. I am actually quite fond of many design decisions and maintain patches to workaround defaults that could drive me insane.

My personal feeling is negative on this matter, just as if I would need to reach to the mouse to delete a character. Up and down mapped to something like page up / page down feels as infuriating as those website that hijack scroll and back button.

I'd just take a look at some patches out there. There's a lot of usability tweaks existing for acme.

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.

I am not bothered by acme / rio issues, since I use acme on plan9port.

However, I have been maintaining a set of patches, including up/down and additional goodies such as bindings for save, copy, cut, paste. Some of them are actually hard coded for Mac (cmd modifier), but not for Linux. It’s workable.

The golang port, edwood, features the same limitations, in my opinion.

I’ve never tried it, but always kind of assumed such basic keystrokes just worked as expected. Now I know I shouldn’t bother with it.

Left and right work as expected. Up and down scroll.

People frequently say this sort of thing, but it's so rare for me to want to move precisely one line up--more usually, I want to move N lines up and M characters over. By the time I've mashed the arrow keys (or hjkl) enough to get there, I could have just as easily grabbed the mouse. Of course editors like vi and emacs have much more powerful movement capabilities, but those aren't "classic left-down-up-right".

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 :)

Being also a vim user, I prefer the arrow keys to the idiomatic hjkl, for anything within a “block” or paragraph. If further away, I would probably “/“ too sh

Maybe I am an incorrigible arrow addict !

There’s a patch to jump to the bar from the text using a keychord, to type and right click, as an alternative to “/“.

I've been using acme for ~6 years now and it's still my daily editor. I wrote a LSP client for it (https://github.com/mjibson/acre). acme is so weird because when you start out it's like "wait so I have to write little shell scripts to do everything?". But then it slowly dawns that larger programs (like acre) are possible that are much more interactive, like modern IDEs.

This looks pretty cool. But I'm having a hard time grasping concept of double-clicking for things like goto definition. Which makes me bring up this question, is acme useable with with 99% keyboard?

It's a single click. There's no double clicks in acme. Did you watch the youtube video? Acme is about 5% usable with a keyboard.

There is a nice Tcl/Tk port of Acme: http://www.call-with-current-continuation.org/ma/ma.html

I'm using it as my day to day tui (with an scratch buffer). I have a index file where I store "shortcuts" to lot of fs places. Also I store action logs of whatever related to shell. For example, a file rabbit.md, it starts with the snippet to portforward the k8 service.. but I also have there some curls to clean or manage things. Files are more or less like a notebook (but everything can be executed or it's just a mix... I can live without it..

Can't

Wait a bit, then you can edit the original.

"tui"?

text/terminal user interface.

That video gets off to a very slow start but by minute 10 or so some very interesting features are on display.

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.

The emphasis on "integrating development environment" is better experienced than what YouTube can render.

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 :)

For example I have a plumber rule where I link issue/123 with GitHub. When right mouse clicking the text the browser opens the issue page.

Quite disappointed, I was expecting a tour of the ACME factory, purveyor of fine items to coyotes in the southern desert ....

pretty cool. I think I could use thisas a pretty damn cool dotnet core code editor with some tweeks.

i used acme to write my summer project at MITLL during my 2016 internship!

Acme must be very useful in a Plan9 system. But on UNIX, I don't see any single thing it does that cannot be done by vim, with some configuration. And of course vim can do more.

Vim is keyboard centric, acme is mostly mouse centric (just taste) I prefer the mouse :)

I have written quite a few hacks to replicate the Acme experience and it includes many tools outside the text editor part: terminal, shell, window manager ...

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 ...

Reply on news.ycombinator.com