Taking Acme for a spin

Posted on .

I've been inspired to take the Acme for a more serious spin. This page is kind of a living documentation page where I put updates when I learn something new, and various tips and tricks.

Instead of installing Plan 9 (which I’ve tried), I’ll be trying out the Linux port to see if I can get used to Acme as my daily editing driver. On Gentoo Linux, Acme is available through the dev-util/plan9port package.

For the best experience, you should have the following setup:

% export PLAN9=/opt/plan9
% export PATH="$PATH:$PLAN9/bin"

On Gentoo Linux this is done automatically, so there’s nothing extra that needs doing.

Getting started

The Acme introduction that’s really piqued my interest (again) is A Tour of the Acme Editor by Russ Cox, so that’s where I started. I’ve rewatched the video a few times now, every time I picked up some new little detail that I’d missed previously.

The first thing to get comfortable with is that the mouse is quite heavily used. Getting used to button 2 (middle-click) being the “execute” function is not that difficult, but I often click button 2 when browsing files and folders (where I need to click button 3 - right-click).

Fonts

I typically like programming with a monospace font, but the default font is not a monospace font.

There are other fonts to try out, they’re all shipped in the /opt/plan9/font folder. To launch Acme with a different font, run:

acme -f /opt/plan9/font/lucm/unicode.9.font

Be sure to target a file with the .font suffix. For now my preferred font is the lucm font shown above.

Using system fonts

I’ve gotten used to the JetBrains Mono font family, it’s just very crisp to read in my experience.

To use system fonts we need to start fontsrv which provides access to host fonts

% fontsrv &
% 9p ls font

which will print out a long list of fonts found on the system. The JetBrains Mono I typically use is given as “JetBrainsMonoNL-Light”. To launch Acme with this font:

% acme -f /mnt/font/JetBrainsMonoNL-Light/11a/font

There are actually two arguments for fonts accepted by Acme: -f and -F. The former (default) is the variable width font and the latter is known as the fixed-width font.

Among the builtin commands understood by Acme (like Cut and Paste) there’s Font. Just putting “Font” somewhere in a tag or body of a window and clicking it with mouse button 2 toggles the font of the body the window.

Running in i3 I’ve ended up with the following way to launch Acme:

% cat $HOME/.bin/Acme
#!/bin/bash
i3 exec --no-startup-id acme -f /mnt/font/DroidSans/11a/font -F /mnt/font/DroidSansMono/11a/font

I am really trying to get used to a sans-serif non-monospaced font for writing code - I find it pretty cool to have an editor that supports pretty much any fonts you want and can set fonts for individual windows.

Tips and tricks

Formatting files

The source for this page itself is written in Markdown (converted with commonmark). I like to have the source wrapped at 80 characters just so the input for the HTML is also readable if all you have is the source. Acme itself doesn’t do automatic word-wrap as you might have in something like Vim with “:set tw=80”.

What we can do instead is to put the text “|fmt -80” in the tag of a file buffer, highlight some text in the body we want to format, select all of the command (including the -80 argument) and clicking button 2. This should format the selected text in place.

If you write C and want to format with clang-format, the same thing applies: Write out “|clang-format” in the tag, select the entire body of the window and execute. To select the whole buffer execute the text “Edit ,”

Setting the tab width

Put “Tab N” in the tag or body of a window, select and click with button 2. Boom! Supposedly the variable $tabstop is also respected.

Running a terminal

Type “win” somewhere and execute it with button 2, and a kind of “terminal” is executed. Win is a C program that receives commands when executed with button 2, and returns the output of those commands. So it works sort of like a terminal. The benefit here is that the buffer holding input and output is a regular acme buffer, and things like recalling and editing a previous commands amounts to searching/scrolling back in the buffer, editing and executing a selection of text.

Things to try out

21-10-2022 Update

I have been running Acme daily now, and thought I’d note down some highlights on the experience so far.

By far the most noticeable adjustment has been writing code in a variable-width font. It’s simultaneously the biggest adjustment, but also the least painful. In this period I’ve been doing work that involves Rust and Python, some devops that involves Kubernetes (editing a lot of YAML), and also solving Advent of Code 2021 tasks in C. Editing languages or markup that relies on whitespace it’s a little daunting with a variable-width font, but being able to toggle the font with simply “Font” makes it pretty much a non-issue. But I find that reading code in a variable-width font is not as big of an adjustment as I expected.

The fact that you can execute any text has the upside that any command you type just sticks around after you’ve executed it. So any “Edit …” commands that are entered anywhere can be re-executed by simple selecting and executing. It stays on the screen, so you can always find it. Compared to Vim, any command that’s executed needs to be recalled somehow to be re-executed.

I think my favorite non-native Acme component to add in is Russ Cox’ Watch. It has brought home the importance of automatic feedback whenever you make any changes, and for me personally it strikes a good balance because it’ll only execute whenever I save a file. In Vim, I typically save all the time (I have a convenient keymapping for that), but I’ve noticed that in Acme I tend to save less often. I presume it’s because it requires a little more effort to go from typing, grabbing the mouse and clicking “Put”.

The increased use of the mouse has both benefits and drawbacks. If your mouse is bad then you’ll have a hard time. My primary challenge has been to middle-click when holding button 1 when I want to select and cut some text. Middle-click is not straight-forward when button 2 is a wheel (which these days it very often is). On the thinkpad laptop that I have, the three-button trackpad is somewhat easier to use. Having a mouse with three equally-sized buttons is almost a necessity.

I would like for the up and down arrow keys to move up and down between the lines - that’s probably something that can be patched in the codebase.

I still have to explore the plumbing capabilities - right-clicking on links doesn’t work. I think I need to start “plumber” somewhere and let it run.

Re{sources,ferences}

There are quite a few good resources out there.


Articles from blogs I follow around the net

In praise of Plan 9

Plan 9 is an operating system designed by Bell Labs. It’s the OS they wrote after Unix, with the benefit of hindsight. It is the most interesting operating system that you’ve never heard of, and, in my opinion, the best operating system design to date. Even …

via Drew DeVault's blog November 12, 2022

Making Hare more debuggable

Hare programs need to be easier to debug. This blog post outlines our plans for improving the situation. For a start, we’d like to implement the following features: Detailed backtraces Address sanitization New memory allocator DWARF support These are rou…

via Blogs on The Hare programming language November 4, 2022

bloat

the actual problem with bloat

via orib.dev September 26, 2022

Generated by openring