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.
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.
(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 :)
Also wish Russ had shown acme in a full screen setup, one of the most awesome things about acme is how well it manages having tons of windows, and you don't get a real feeling for it without seeing it done in a real full screen large environment.
I know lots of people have strong feelings about this highlighting or that, but honestly, just try going without it for a week or two. I bet you'll find it is not that big a deal after all.
 (How strong? Well, the current frames I'm wearing aren't the frames I initially chose; they're the frames I chose out of the set of frames that have the earpieces connected far enough back to allow them to fold closed given the thickness of the lenses I wear. The fact nobody warned me about this when I picked out my first set of frames indicates it likely doesn't happen a whole lot.)
Just keep your code window small enough that it doesn't make your eyes glaze over.
With per format program, possibly implicitely called based on extension, it could be extended to structural reference.
/foo/bar.c:function/statement would call an ANSI C parser and return the substream enclosing the :/expr/ passed.
I don't think there's a good reason for this to live inside the OS, instead of simply running as a service. I don't think there's any extra functionality or elegance that would buy you.
http://russ.cox.usesthis.com -- `rsc`, do you still use this setup?
Sounds a little like Oberon. I wonder how many people have used both.
This can be seen even more clearly in Acme's more direrect predecessor: help
Rob Pike (about 2 hours ago) : What Russ doesn't stress enough is the major thing Acme brought, beyond what it borrowed from Oberon etc.: the contextual right click. One button click gets what I want, be it the next appearance of a word, the line the compiler's complaining about, a man page, a PDF file, a UPS delivery notice, whatever. If the data's here, jump the mouse to the location (another thing Russ didn't point out) and highlight it. If it's not there, load it and jump to it.
One click, context-driven. It's hard to appreciate how powerful and effective that is without trying it.
My Oberon usage was quite a while ago (really liked the system, although it was a bit impractical). The big difference being the object-/module-oriented nature of it, as compared to acme's Unix text piping.
Oberon's System 3 is a pretty decent example of transitioning from a text-based environment to a richer GUI, by the way.
Definitely not an environment to work in if you have cats/kids that like to fiddle with your mouse when you're in the kitchen or taking a bio-break.
And preferable not a C/Go unix CLI/server, where you probably have decent cooling and can stay within acme all the time. The trivial blog web app example would be interesting, maybe in Java, Ruby, Perl, Python etc., so that it's easier to compare this with IDEs or vim/emacs.
The swtch.com machine has a fairly slow connection. Better ways to get it:
- hg clone https://code.google.com/p/plan9port plan9
I changed the link on the home page to point to that tgz instead.
so to summarize, we'd need an editable terminal, like the one acme provides and a plumber that works with that termal, put it all in a tiling wm, and we're there, right?
in my opinion, in a way, the behavior is already very similar to what everyone with tiling wms trys to achieve. but maybe i'm missing something crucial
Before I lost my hard drive, I had some udev rules setup that used the plumber to post notifications to a 9term window on my desktop when a USB drive was mounted. It's really dead simple, really makes you wonder about the proliferation of complex messaging systems like dbus.
Why does it need more than VGA text if it entirely text-based?
It would not be hard to make the underlying graphics code work on top of linuxfb. I think a patch for that might be floating around.
> Why does it need more than VGA text if it entirely text-based?
Did you really watch the video? You can see that while acme is entirely about editing text, the UI itself is graphical.
(I currently run emacs on arch linux with no x)
VGA text is everywhere. No need to switch to Linux (and patch it), switch to OSX, use hardware than runs Plan 9, or any other restrictions. No need to run X11.
It just works.
Granted, I see no real reason for it, as you might as well hook the existing code into e.g. Linux' framebuffer mode, instead of porting it to curses. It would run over ssh, of course, but so does acme with X forwarding, and the best general solution would probably involve merging sam's client/server mode with acme.