Very neat. It seems to me the really interesting bit here is the ability to add execution meaning to arbitrary bits of text. Can anyone who uses Acme comment on whether or not that is primarily what gives Acme its power? Is there something else key to it that isn't shown cleanly in the video?
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.
It's definitely the ability to parse expressions like "<file>:<lineno>" and open files at the right position, it essentially makes it integrated with many many unix tools without actually having to write any integration code.
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 won't argue any of your points but one. You can use whatever system fonts you like on OS X. Here's some Comic Sans for you: http://swtch.com/~rsc/hackernews.png
-- 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".
Sorry, my original reply with the screenshot included a command line, but it got lost in the internet tubes, and when I reposted the reply I forgot the command line.
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.
I had seen acme color theme files in a previous plan9port repository version but can't seem to find them today. I believe I was also able to use them. Does anyone remember or know more?
At Bell Labs, Rob switched acme and sam from black and white to color in the development version of Plan 9, called Brazil, in the late fall of 1997. I used Brazil on my laptop as my day-to-day work environment, but I was not a developer. I remember writing Rob an email saying how much I enjoyed having color but that it would be nice to have options to set the color scheme. He wrote a polite but firm response back explaining his position. He had worked with a graphic designer to choose a visually pleasing color palette. He said he believed strongly that it was important for the author of a system to get details like this right instead of defaulting on that responsibility by making every user make the choice instead. He said that if the users revolted he'd find a new set of colors, but that options wouldn't happen.
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.
I think this approach to color selection is a wee bit patronizing, assuming that all users are the same (and gives waaaaay to much credibility/authority to graphic designers). Never mind that even if you agree with the intended choice, you'd need to make adjustments to cope with environmental factors (displays, light etc.).
Interesting but I could swear I had seen some theme files and had succesfully tested them IIRC. It was either for 9term or acme if my memory ain't confused.
The window management is a huge win for me, if you'll pardon the unintentional pun. It's so much simpler and fluid than in Emacs or Vim, at least for me. I just kind of throw windows around and resize them with an ease and speed that I was never able to achieve on Emacs. For instance, when using Emacs I may have as many as 4 windows open at a time, frequently switching buffers around with the clumsy C-x b switching (I know there are better switchers). With Acme, I'll have 30 windows open, most of them stacked up with just the tag lines visible until I need them. When I need one, I just mid-click on the little box and it expands.
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.
(I have used both Acme and Emacs but only a little bit each) I can believe that most of the time it is easier to switch to the mouse to move the cursor where you want if it is no where near your current position. But what about just moving up and down one or two lines? Do you really just use Ctrl-A twice to go up a line? Or do you use the mouse? Or is there some alternative that I haven't heard yet?
As you say, there are great use cases for just having a simple keyboard shortcut. Ron Minnich made "smacme", a modified acme with the basic Emacs C-f, C-b, C-n, C-p bindings in; you can find it in the sources directory IIRC, but in any case it's really a pretty simple hack.
I've only found a reference in a 2006 post from Ron. Is it a modification to acme which would need to be ported to plan9port or is it already part of plan9port's acme or is it maybe just a set of scripts to source on acme startup?
Have you written up a summary of your experiences? I would love to see a comparison from an Emacs user that switched to Acme.
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 haven't written up a big summary, just occasional posts like this on HN and elsewhere. I started life as an Emacs user, switched to Vim, flip-flopped between the two for various tasks. The whole time, in the background, I was playing with Plan 9 and Acme; eventually I got sufficiently addicted to Acme that I dropped Emacs and Vim for most of my editing. I still use Emacs as a mail reader (and nothing else), Vim for quick edits or working on a remote system, and Acme for everything else.
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.
Thanks. I find a lot of the Plan 9 stuff very fascinating, and I often think about what it would take to port some of the functionality to OSX.
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.
Emacs buffers ergonomy is quite low. I found some elisp to transpose buffers layout (pretty awesome). Some maximize / shadow code would be handy. It would be great to have one layout lib included in standard distro.
Some extensions like FFAP (file-find-at-point) lookup the word at point in the filesystem, some leverage font and mouse infrastructure to turn text into action.
10$ it's quite easy to do, a generalized *-at-point, the "challenge" is to make it as configurable.
Unknowingly I just reimplemented part of FFAP. After a little playing with Acme I want to add some of its features to my emacs (FFAP is one of these, since click/command opening included files in my .tex or code is great)
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 :)
No, I used to hold some code in my googlecode repo, but gave up a long time ago. Until I get more proficient with git, I'll probably just post it in my blog (and then the marmalade-repo, just like I did with gnusnotes.el) when it is decent enough for general usage
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.
Isn't it annoying to program without syntax highlight? Or is it just some false rumor I've heard that acme doesn't have that feature... it looks a lot like wmii. I have to try it though, emacs and vim really sucks, too bloated for my taste, I'm still not that hardcore that I use ed for programming so I'm searching for an simple, minimal and correct alternative to emacs and vim....
For a number of years in the mid-1990s I switched between Borland's IDE when using DOS and vi (not vim) and later sam when using Unix. The fact that one world had highlighting and the other didn't have it had no effect on my productivity, at least not one in favor of highlighting. It never occurred to me that I should miss it on Unix or that it was annoying not to have it. They were just different tools that did different things.
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.
My glasses are likely stronger than yours [1] and I've never had a problem with chromatic aberrations. Are you nearsighted, farsighted, or something else?
[1] (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.)
I doubt the dispersion is caused by any specific properties of my lenses but rather by how my preferred desk arrangement makes me often look off the lens' axes. I could get contacts, but since reading programs is the only time it bothers me, and I otherwise like the rainbows, I just tell all my programs to show normal monochromatic text.
It varies from language to language I'm sure but in C there's enough syntax and sigils and what not that it's easy to parse visually without colorized hints.
Just keep your code window small enough that it doesn't make your eyes glaze over.
I think you hit the nail on the head. I have no problems using C or Java without highlighting, but I wouldn't want to use Python or even Fortran without it, there's just not enough guidance for my taste.
The plumber is effectively at the OS level. It's a userspace program, but it provides it services to the whole system at once. It's a global service that handles all plumbing between all programs. (Think "Android Intents". It's not too far off, conceptually.). Running, for example,
plumb path/to/file.c:123
will send the file to whatever editor instance is set up to handle C files, and move the dot to line 123, from wherever it is invoked, be it the command line, the
plumb bar.jpg
will open bar.jpg in whatever image viewer is appropriate. More or less, you can think of the plumber as a system level "take this text and do an appropriate action with it" service, where you can set up whatever rules you want to do the plumbing.
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.
Conceptually I love Acme, but the three-button mouse thing has turned out to be a real problem for me. I don't think I can work without a scroll mouse, and I've never found a mouse that has both three real buttons and a scroll wheel. Can anybody recommend one?
Yes, that's still my mouse of choice. On a Mac you need a 3rd-party tool like 'USB Overdrive' to remap the buttons correctly. On Linux you can use xmodmap.
That's true, but it's very awkward. In Acme, the middle button means 'execute command'. You need to press it constantly, often in combination with other buttons. A clickable scroll wheel is not good enough.
How can this be? In the example he managed to click on things to run commands by just clicking on the word, instead of selecting the entire line perfectly.
Thank you. I didn't know there was a direct influence. It's intriguing, because the two cultures share a similar design style: "aggressive use of a small number of abstractions" as Ken Thompson put it. I like that design style.
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.
I think the line of descent is Cedar -> Oberon -> Acme.
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.
Great screencast. I tried to read through the Acme guide before but never quite got the gist of it. This reminds me of the Starcraft interface in that if you have excellent mouse twitch reflexes it seems you can more easily induce a sense of flow (whether you're productive or not is a different matter; see APM spam[1]).
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.
I fiddled with acme a few times over the years, but never got around using it for a real project (I did use sam for quite a while about 10 years ago). I'd like to see the "advanced" version of this screencast, i.e. someone doing a small programming project with it, coding, debugging etc.
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.
From the looks of it, everyone on HN is currently downloading Plan 9 from User Space. It's a 51MB download and the download speed is currently 3-4kB/sec!
ok, looks interesting. i still like my vim though as the editor part.
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
It would be really neat to integrate the plumber into one's usual development environment, be it vim or emacs or whatever. I'd like to do this with vim, but I thought I'd ask first: Does anyone here already do this (with plan 9 from user space)? Any hang-ups I should be prepared for?
All you need is some sort of remote control for your tool -- for example, a way to open a file in an existing emacs instance. plumb is just a command like any other that provides global ipc between all your programs,
plumb "path/too/foo.c"
runs the argument string through the gauntlet of plumbing rules. It's up to you to edit the plumbing rules to send the file to your editor.
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.
I like that Acme has such a radically different paradigm from vi, but I can't imagine that pixel-dependent mouse interactions could ever beat vi for text manipulation. (It takes me a maximum of about 4 keystrokes to get anywhere I want in a vi buffer.)
Russ do you prepend plan9port/bin to PATH when using acme as a way to prefer tools which do not make use of escape sequences for coloring term output? Or do you disable color in tools like mercurial?
Execute the command "Indent on" to turn auto-indent on for the current window. Acme will then automatically insert the same indentation as the previous line for every new line you make. I just tested, it works with tabs and spaces. (But don't use spaces :-)
No, we don't support startup scripts in Acme (you could implement it of course, the code is simple), but you can use the "Dump" command to take a snapshot of your current Acme layout. I'm not sure if that will preserve the status of Indent, but it may at least help you.
Russ, you probably remember that Aki did a linuxfb version of drawterm for Tiny Horrible Xen; I'd bet the changes could be adapted to Plan 9 Port without too much trouble, really the Linux framebuffer is pretty simple.
If you install Plan 9 Ports, check out /usr/local/plan9/src/cmd/devdraw. Russ can correct me if I'm wrong, but I think that's the only place the graphical programs interface with X. You'll need to find the places where devdraw is using X, and replace them with framebuffer code.
Not only have I watched the video, I've used acme.
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.
Hmm? Apart from the proportional text what would you lose? Even IBM line drawing characters should be able to simulate the scrollbars and dividing lines. Given a sufficiently high-resolution text mode, multiple columns should pose no problem, either.
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.
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.