I remember when this was first published, I watched the video and then rushed to install plan9port and try Acme. I used it for a couple of days before going back to Emacs, but Acme did leave a very positive impression on me.

- I really like how "unixy" of an editor it is; you can easily add new editing commands by writing a small program that reads from stdin and writes to stdout and use it to manipulate text within Acme. Of course, that program could be a shell script, a Python program or a Java program; Acme only cares that it can give and receive text.

- The editor has a mount point that contains the configuration of the editor and this can also be manipulated by external programs to influence the editor.

- The concept of addresses (e.g. an address into a file, an email address, a URL, etc.) and being able to click on such an address and have the editor DWIM is very powerful.

- I still don't know how to classify Acme: is it a minimal or a kitchen sink editor? You can make it do anything you want, but out of the box it is extremely bare. Is it a programmer's editor or a general purpose editing tool?

I'm not leaving my trusty Emacs, but I'm happy that I took some time to get to know something that was completely different.

It's definitely a programmer's editor. Some notable programmers used acme (Dennis Ritchie, Russ Cox). A lot of very great ideas/softwares were written inside acme (plan9, UTF-8, Go, etc).

But I agree that it's not the best choice for some languages or environments.

What was written in it?

According to the Acme page at acme.cat-v.org, it was "implemented in the Alef programming language, and later rewritten in C using libthread".

I'm fascinated by the expressiveness of the mouse in this demo. I've seen the mouse as a lost cause ever since committing to vim some time ago, but this video proves that I am wrong, very wrong. It's clear that the expressiveness of a UI is limited by it's designers not the hardware.

Plan 9 in general reflects this ideology and concept. The entire operating uses the mouse very expressively to the point that when I develop outside of a mouse expressive UI it feels lacking. Among other things, the mouse chording used in Plan 9 is available almost everywhere in the OS. Ex. L+M=Cut, L+R=Paste

The cut and paste is an old Unix thing. It's not just plan9.

Yes. But the graphical UI interface he's talking about was lost with the advent of Xorg.

The same (or very close) interface was available for unix in 1982 with the Blit graphics terminal. Blit was created by Rob Pike (acme creator) too and it influenced the next Pike's GUIs (rio and 8½).

In Plan9's rio, windows are treated as completely editable text, then the mouse chords for cut-and-paste works for all applications transparently.

Blit promotional video: https://www.youtube.com/watch?v=emh22gT5e9k

Wiki: https://en.wikipedia.org/wiki/Blit_(computer_terminal)

I'm using acme for C/Go development for at least 8 months and I'm very satisfied. Acme is very stable and so much easy to extend using any language or simply shells. This turns the development a task much more painless.

In my current view, the lack of syntax highlighting is a great feature!

For now emacs is only for lisp/scheme languages.

It's interesting to me that shell integration is becoming a harder problem with editors these days. Emacs has a multi-term which kind-of works (there were many packages before this that didn't work), Vim does not have a package that can present a prompt (afaik), and Atom finally has a near-perfect terminal in the form of the term3 package.

What Atom considers bare minimum is stuff that Acme doesn't even think about: syntax-highlighting, auto-indentation, and auto-complete.

Why should a text editor even have a terminal emulator?

I think it's less about having a terminal emulator and more about having access to the shell environment. In the case of acme no terminal emulator is used but you still retain access to the system tools you are given and typically access through a shell.

In the tag bar, type Win and middle click. You'll get a terminal.

You can definitely see why in the video, starting from 15:25. I don't use terminal emulators, but for other editors and from my experience, it's the keybindings and the text processing on the shell output. Acme took that to an extreme.

Acme has a terminal, and a web browser, and a mail client, and a news reader

Acme doesn't have web browser and news reader natively.

For terminal, acme have support for windows attached to programs (if the program is a shell, you have something like a terminal). From the manpage:

    Win creates a new acme window and runs a command (default /bin/rc) in it, 
    turning the window into something analogous to an rio(1) window.
    Executing text in a win window with button 2 is similar to using Send.

Mail client is builtin but only for upas/fs. If you want/need another approach you can extend by external programs.

Some other applications of plan9 have taken the advantage of acme UI (like abaco web browser) but they aren't builtin inside acme.

I know. My friend FGB wrote abaco. I have code in the distribution (in faces) and the screenshot on the Wikipedia Acme page is from my screen [1] - though it was Uriel who put it there.

plan9 is meant to have very little "native". Even moving to line number 4 with :4 is not native, it's in the plumber.

[1] https://upload.wikimedia.org/wikipedia/commons/thumb/9/98/Ac...

Very nice!

Yes, plumber is the app behind the scenes that make acme so much integrated with OS and other apps. The same applies for right-click on the text between '<' and '>' in includes (in C source files) for opening header files. That's the kind of programming environment that I miss when using emacs/vi.

It is all sorts of awesome. (sorry this is so long :)

In that screenshot I am editing PHP files on an OpenBSD box at the colocation. It is running u9fs tunneled over ssh so I can connect to the filesystem via 9p.

I have three plumbing rules for editing PHP.

One window runs the shell command "tail -f /n/momo/var/log/httpd/error". From there I can plumb

    Syntax error in /path/webpage.php on line 56

It extracts the filename part "/path/webpage.php" and line "56". The web server is chrooted.

It then checks if /n/momo/var/www/path/webpage.php exists and if it does it opens that file at line 56

If I plumb a file ending in .class or .inc it looks in /n/momo/var/www/php (my include directory) and opens it if it exists. This is so I can plumb file.class in include("file.class") in php files

The final one fires if I plumb "validfunctioname(", it runs a shell script on the server and greps for that function in all my php files.

I use the plan9 method of defining functions with

    function
    validfunctionname(args)

so that grep -ni '^validfunctionname(' will work.

So I had what most people would think a pretty useful PHP ide in twenty lines of code.