The ease of piping the selection through an external program is a close second.
However I do not use it.
What's funny about acme is that it's a perfect metaphor for the entire plan9: it shows you how striving for a simple, beautiful design can create new, great solutions to old problems.
But at the same time it will also kill the adoption of the product completely: acme doesn't support any keybindings (doesn't fit the desing), no syntax highlighting (not the editor's job to parse code), nothing but bitmapped fonts (implementing externally defined standards is a chore), tags file support (doesn't fit the design), incremental search (doesn't fit the design), horizontal scrolling (makes it complicated to use the same editor control for the tags too), configuring the color scheme (no), weird non-standard behaviour of up and down keys (we just like it better this way)...
Bringing any of this up to a 9fan will also be a great metaphor for the friendliness of the community.
I tried starting Acme as follows, but no joy:
9 acme -F '/Library/Fonts/Comic Sans MS.ttf'
ADDED. After googling site:swtch.com, I tried the following two invocations, but still no joy:
9 acme −F /mnt/font/Monaco/13a/font
9 acme −F /usr/local/plan9/mnt/font/Monaco/13a/font
-- which is not so surprising as neither /mnt nor /usr/local/plan9/mnt exist.
ADDED. Actually, cannot get the -F flag to Acme to do anything. E.g., $PLAN9/font/luc/latin1CW.18.font exists, but Acme started with "acme -F $PLAN9/font/luc/latin1CW.18.font" uses the same font as Acme started with "acme".
Still would like to be able to choose a OS X system font, though.
acme -f /mnt/font/ComicSansMS/16a/font is how I made the screenshot. Run fontsrv -p . to get a list of the fonts you can use.
It was really a marvelous email, polite yet firm and a crystal clear explanation of his philosophy. Over the years I have from time to time spent hours trying to find a copy of that email. It is lost.
But I can say definitively, both as a matter of philosophy and because I did the lion's share of the open source release work for both systems since color went in, that there have never been color theme files in the Plan 9 distribution, nor in plan9port.
Execution of arbitrary text and loading/plumbing files/text with the mouse buttons is also really powerful for me, as you point out. I haven't finished watching the video yet (I'm at work), but in case he doesn't cover it, mouse chording is one of the most important capabilities in my mind. Makes copy-pasting significantly quicker.
http://acme.cat-v.org/keyboard
(oh and I really miss moving back and forth by word and incremental search with keyboard, I have nothing against using mouse for other things though)
So many of the concepts just seem painful to me at first glance (What? I have to use the mouse for things?) but I am sure that there is some merit to them, given that some of the greats used it.
What OS do you use it on, and what is it like using the plumber with other (non-Plan 9) components of the system?
I don't actually take the Plan9Ports thing as far as I could (I work on Linux, mostly, often with a drawterm connection open to our Plan 9 server). I run a plumber, and Acme, but I don't run rio (the window manager) or 9term (the xterm replacement), which means I'm going to miss out on some of the plumbing stuff. Mostly I just run the plumber so I can say "B <filename>" at a shell to have it pop up in my Acme.
I find it interesting that you mentioned the window management as being one of the big selling points. I have been working on a tiling window manager for OSX, and might try adding a mode like that. It would mean splitting my emacs into frames, which could be weird. Probably worth messing around with, though.
Also, I have several emacsclient based commands to do things like the plumber/acme, but is a pretty poor attempt at reimplementation.
I was also thinking - how hard would it be to add this to Emacs? does it already exist?
10$ it's quite easy to do, a generalized *-at-point, the "challenge" is to make it as configurable.
Next step is making my FFAP more intelligent (depending on buffer extension & mode) and then make it "execute at point" if it is not intended to be a file (depending on context)
Don't expect anything fancy (at least yet... My free time is close to 0, I'm doing this while waiting for something else to finish...) I'm still deciding what I want it to do and how. For now, the magic function does its job... (I can open included files in TeX documents and jump from TeX output undefined lines to the respective file and line.) And my code is full of messages and lacking a clear structure of region selection. I need many helper functions down the road. But stay tuned, everything can improve :)
Interestingly, I also see Light Table as an "Integrating" Development Environment - something that utilizes all the amazing tools out there and strings them together into a very fluid workflow. I think we need to decouple the raw functionality of dev tools from the experience of their use, since it seems to me the latter is infinitely configurable and far too subjective to get "right" in all cases.