
A Tour of Acme (2012) - gklitt
https://research.swtch.com/acme
======
floren
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](https://i.imgur.com/Trg79NS.png)

~~~
haolez
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?

~~~
floren
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](https://news.ycombinator.com/item?id=23782439)
and [https://github.com/fhs/acme-lsp](https://github.com/fhs/acme-lsp)) but I
don't use them... I'm old-fashioned.

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

~~~
floren
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](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.

~~~
gnuvince
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](https://vfoley.xyz/syntax-highlighting/purp3.png)

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

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

~~~
4ad
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.

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

~~~
4ad
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?

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

------
mjibson
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](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.

~~~
tennineeight
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?

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

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

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

~~~
palsir
"tui"?

~~~
masklinn
text/terminal user interface.

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

~~~
jeromenerf
The emphasis on "integrat _ing_ 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 :)

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

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

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

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

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

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

