Let’s Try Acme: Episode 7 - Equilibrium

Guys. I like Acme. Seriously. I’ve been using Acme for all my PHP and Clojure development the past month, as well as a bit of general text editing (for instance, this blog post). I like it. Quite a bit.

This is going to be a pretty long post, folks. Fair warning.

It seriously helps that I have an actual three-button mouse now (clickable scroll wheels suck). The ability to quickly click the middle button without having to worry about accidentally scrolling, thus highlighting the wrong thing and executing a bad command, has sped up my usage to a surprisingly significant degree. I can do almost everything with my MacBook’s trackpad that I can with a mouse using option-click as middle-click and cmd-click as right-click. I can even “chord” by selecting text, not letting up on the trackpad, pressing option to “cut”, and then pressing cmd to “paste”. This is the same as the 1-2 and 1-3 chords using a mouse. This isn’t as convenient as a real mouse, but does allow me to not be tied to a real mouse all the time. The only thing you can’t do with the trackpad is 2-1 chording. (Note, the numbers like “1-3” mean to hold the button for the first number down while pressing the second number. “1-3” means “hold down button one [left click] and press button three [right click]”.)

I spent some time trying to think how I could describe my Acme work flow. I’ll do my best to describe how I use Acme and why I feel like it’s working for me.

Let’s start at the beginning. Since I have two main projects I’ve been working on, I’ve used Acme’s Dump and Load commands to save and load the window state. It’s quite nice, actually, since it reloads everything, including anything I’ve added to any tag bar. I typically start a session by deleting all existing columns so that Acme is empty, then load the .dump file for the project I want to work on. I now have all the windows/tags/etc back the way they were when I ended my previous section (provided I remembered to Dump the state).

Now I have all my windows how they were at the end of my last session for that project. Great. Usually, the next thing I do is run a git status and run tests, just to make sure I’m starting from a clean state. This is easy enough. When I first start on a project (the very first time), I start with the root project directory open in a window, then run git status from the tag bar. This opens up a +Errors window for that directory (ignore the name, this is a very good and useful window) with the output of the command. From here on out, I will use this window to run commands, including git and running tests, instead of the main directory window.

The great thing about this window is, because it’s just text, I can type anywhere or modify and use any existing text. A couple of examples:

• I run git status and see a file needs to be added. I can simply type git add in front of that file inline in the git status response, then use middle-click to execute the command.

• I run git status and see that there are changes to be pulled. The git output says something like Use "git pull" to get the changes., so I can use the existing text to execute git pull with middle-click. (The double quotes around git pull make this even easier, but we’ll get to that in a bit.)

Keep in mind that, in order to run a command, I just type it anywhere in the +Errors window and use middle-click. However, having to find the command in the window each time is a pain, so I put common commands (usually git status git commit and make [or whatever I’m using to run tests]) in the tag bar. Instant access.

Remember what I said about double quotes? If you click on a word with middle-click, Acme will try to execute that word as a command. If you need arguments to the command (like git status), you can use middle-click to drag and select the entire command. It will be executed when you release middle-click. Alternatively, you can drag to select the command with left-click, then middle-click the selection to execute. Of course, if you do this in the window itself, you lose that selection whenever you select anything else. If you put the command in the tag bar and selected, it will stay selected until you select something else in that tag bar. This means that I can keep git status selected (because I use it a lot) and just middle-click it without having to worry about having to select the command first.

Double quotes make commands with arguments even easier. In Acme, if you double-click just inside the first or last of a grouping pair of punctuation (quotes, brackets, etc), you will select the contents inside. So, if I change git status to "git status", I never have to drag to select; I just double click between " and g. Why would I need to do this if the command stays selected for me? When I need to run another command.

For instance, say part of my tag bar looks like "git status" "git commit -a". Usually, I’ll have git status selected so I can execute it immediately. When I’m ready to commit, instead of having to drag to select the entire command to execute, I simply double-click just inside the opening double quote, then middle-click to execute. I then double-click just inside the git status double quotes, and I’m back to having that selected and ready to go.

When it comes to running other commands like unit tests or git diff, the window works the same. Any commands I don’t keep in the tag bar (like git diff) I just type into the window and execute from there. Being able to use existing output as editable text and executable commands is extremely handy; there’s little need to hop out to a terminal.

I’ve described all this productivity, and I haven’t even opened a file yet! I’ll point out here that, since the +Errors window will fill up quickly, you can always clear the window (e.g. Edit , d). You can also delete any chunks of text in the window you don’t want or need, allowing you to leave a curated window of output that could be useful for making instructions and examples that can be saved and distributed.

Now, let’s actually get some work done. If I’m not starting fresh, I’ve already got some files and directories open to get me going, but let’s continue on with the starting fresh example. I’ve got my main project directory and its +Errors window. To open a file, if I get it in output at some point in +Errors, I can right-click it to open (if the path and such is correct, though the plumber can be customized to make this easier and more robust). However, if I need to open some other file somewhere in the project, I have to do so manually. This is one of the drawbacks of Acme. In order to open a file, I either have to right-click through directories starting from the project root (each directory will be in its own window) until I get to the file to open (which is done with right-click), or I can open a new window and type the file path and name into the left part of the tag window (Ctrl-f for completion) then also type Get into the tag bar and middle-click it to load the file.

Both of these methods are a bit more cumbersome than other editors, but they aren’t too bad once you’re used to it. Usually I’m not starting with a blank slate, so I have a better place to start. For instance, if I have a file open, but need to open a file elsewhere in the same directory structure (say, two directories up), I can right-click select the portion of the file path in the tag bar that is the directory I need to get to and that directory will open. So, if I’m in /Users/me/dev/file and I want to get to /Users/me/, I can drag with right-click on that text and let go to open that directory. I can also select with regular left-click dragging, then right-click the selection.

Now that we’ve got some code open, we’re all set. Type in some code, middle-click Put to save, middle-click make (or whatever your test command is) in the +Errors window tag bar, occasionally run other commands like git, rinse, repeat. As far as editing goes, there’s lots of mouse usage, but it actually works to your benefit. Mouse chording (covered in previous posts by myself and many others) is a wonderful thing. The only issue I still commonly have when editing in Acme is the up and down arrow keys being page up and down instead of cursor movement. Need to go up or down a line? You have to click. This continues to be the one thing I wish were different about Acme. I don’t need to arrows to scroll, especially since scrolling in Acme with the mouse is quite nice already, and since you have to use the mouse so much anyway, it’s not all that inconvenient.

Speaking of scrolling, the way it works takes a bit of getting used to. Using middle-click, you scroll more or less like how you would expect in other programs. However, the left and right buttons are different. Left-click scrolls up, and right-click scrolls down. This seems backwards, but I’ve gotten used to it pretty quick. The interesting thing is that those buttons scroll in their respective direction regardless of where the mouse is in the scroll bar. The mouse’s position in the scroll bar determines the amount the window scrolls. Towards the top of the bar scrolls one line; towards the bottom scrolls a full page. It’s actually a pretty powerful mechanism that allows some pretty accurate scrolling.

Anyway, now we’ve got all we need to use Acme and get some work done (sort of - more on this soon). I’ll interject here that I rarely (never, really) miss having colors and syntax highlighting. However, indention can be a contention in Acme. In Acme, tab is tab, no matter what. Want spaces? Use the space bar. I prefer spaces myself, so this can be in a issue. “No problem.” You might be thinking. “Auto-indent will solve this!” Well, sort of.

Acme gives you two options for auto-indention: none and match previous line. The latter (which you get by starting acme with the -a option) does exactly what it says. When you press return to get a newline, whatever the previous line has for indentation is copied and placed for you at the beginning of the new line. This includes copying spaces and tabs as they are. You still have to manually indent further in if, for instance, you’re going inside an if statement and need to be indented further than the if line itself.

What about mass indenting? Say we remove an if and need to “de-indent” the code that was inside. We select the code (with the mouse, of course), but then what? This is where Acme’s reputation as an “integrating editor” comes into play. Acme gives you essentially the bare minimum (not quite completely bare, but relatively bare compared to many other editors) to do your editing. Everything else is left to external programs and resources. An Internet search will provide you scripts and such that people have written to do things like mass indentation (search for the a+ and a- scripts). You can also do other things, such as spell checking and getting the current date, by calling external scripts and programs. You can use <, >, and | to redirect information to and from these programs. For instance, when I’m keeping time of when I worked on certain projects, I go to a time sheet text file, go to a new line, type |date, select it (press Esc to select the most recently typed text), and middle-click it. This runs that command on the system, takes the output, and pastes it into the window at the cursor. Since the |date command itself is selected in my case, it gets replaced with the actual date and time.

One other complaint I had in a previous post was concerning window management. At first I didn’t like it. Then I discovered that using the middle and right buttons, you can maximize or “full column” (like full screen, but within a column) windows to de-clutter a bit. Moving them about is easy, as well. To do any of this, you interact with the little box in the upper-left of the window, the thing all the way to the left in the tag bar. Again, this is required mouse usage, but it works to your advantage and even feels intuitive after a very short period of time. The window management still feels different, but I no longer feel like it is getting in my way.

So, that’s the basics of (really, a pretty complete look at) my Acme workflow. Typing it out and reading it back makes it sound like a lot more work that it really is. I do find myself quite productive using Acme and still find myself missing certain aspects of Acme (like mouse-chording) when I’m using other programs.

Seriously, guys, I recommended giving Acme a fair chance.

This post was written in Acme.

In the next post, I finally begin to grok two important basics of Acme: scrolling and plumbing. You can read the previous post here.