# Exploring Acme, Plan 9, and `NO_COLOR` _Published: April 19, 2022_ For the past couple months I've been exploring Plan 9, a distributed operating system from Bell Labs from the same group that developed UNIX and C. It's been a pretty deep rabbit hole, so I thought I'd write about it here. ## How it Started It all started with an interest in tooling. I'm generally really interested in human-computer interaction, and Plan 9 presents a radically different approach to using a computer. I watched Russ Cox's [Tour of Acme](https://research.swtch.com/acme) (a text editor that was written for Plan 9) and was blown away by the way the plumber allowed hyperlinking plain text through a simple rule-based system. If you haven't seen Acme in use, I'd highly recommend watching that first. After reading everything I could about Acme, I knew I wanted to give it a try, so I downloaded [plan9port](https://9fans.github.io/plan9port/) (a userspace port of many Plan 9 programs) and tried to integrate it into my workflow. ## Early Days: Trying out Acme Trying to code in Acme was immediately jarring. I had grown fond of dark themes and syntax highlighting, so the cream colored background with plain black text seemed washed out. After the shock of the colors came the reality check: I'm no good with a mouse, and Acme requires precise mouse use. Acme not only needs a three button mouse (select, execute, and plumb/open), but common operations like copy/paste use mouse chording (i.e. button 1 and 3 at the same time). Now, I've invested countless hours into learning Vim and have years of muscle memory built up. I've chosen keyboard-driven tools wherever possible. So to type on something that lacks what would be considered primitive keyboard motions (up/down scroll, don't move the cursor) was a huge adjustment. Even so, that wasn't the end of my trial. I swapped my trackball for a real mouse and gave it an earnest shot. I really enjoyed the right-click to plumb and grew fond of the colors and simple stacking interface. There was also a certain appeal to it's take on extensions--rather than have an extension language like VimL or Emacs Lisp, Acme presents it's contents to other processes as files on a filesystem. The user can write programs in any language to interact with Acme, which is so cool. Unfortunately, I didn't have the time to invest into fully customizing Acme via scripts. And given the spartan interface, I really did need to to continue to use it. For example, the TAB key inputs TAB characters. To write Python you'd need to use a script to convert them to spaces. Ultimately, I chose to crawl back to tools I was familiar with. ## Middle Ground: Bringing Acme to my Tools Acme was too hard to transition to, but I was still bent on bringing the benefits to my existing tools. I focused on two things: 1. Building a "plumber" (to decide how to open/display things) 2. Trying out the monochrome colors ### Building The Plumber This turned out to be rather easy. The key realization was that `tmux(1)` allows external programs to manipulate the session. So with `tmux` as my replacement for acme-windows, I was able to write a [`plumb`](https://git.sr.ht/~akarle/dotfiles/tree/main/item/bin/plumb) script that takes in text from the `tmux` selection and opens it in the browser if it's a URL, `vi` in a new split if it's a file, `man` if it's a man-page, `git show` if it's a SHA, etc. To make this useful, I paired it with several hotkeys that use the `search-backward` `tmux` command to search for all instances of a `plumb`-able object. For example, `prefix-H` finds URLs in the scrollback: bind-key H copy-mode \; send-keys -X search-backward "http[^ ]*" Then the `'a'` key in `copy-mode` (while searching) sends the URL to `plumb`: bind-key -T copy-mode-vi a send-keys -X copy-pipe-no-clear "plumb #{pane_current_path}" After a couple months of use, I've found that while searching for man pages and git-sha's are a cool screensharing trick, I only really use the URL search. For files, it's nifty that I can teach `tmux` to open the output of `grep -n` to the exact line, but I've found that I generally don't want that many Vim's kicking around. In other words: Acme did it better. `tmux` can create the splits, but it doesn't feel cohesive since not all splits are editable. ### My Life in Monochrome This was a fun experiment. Apologies upfront to Cal, my work friend who had to go through it with me while we paired a feature :) Rob Pike (the author of Acme, amongst many other achievements) has been [quoted](https://groups.google.com/g/golang-nuts/c/hJHCAaiL0so/m/kG3BHV6QFfIJ) saying that "syntax highlighting is juvenile". I wanted to know why. Could monochrome code really make me a better programmer? So, one evening I configured all of my tools to disable color using the `NO_COLOR` environment variable and individual settings as described at [https://no-color.org]. I updated my terminal to be Acme-cream colored and wrote a Vim [colorscheme](https://git.sr.ht/~akarle/dotfiles/tree/main/item/.config/nvim/colors/acme.lua) to match. I was ready to take the plunge. The initial feeling of switching to `syntax off` was that of being lost. I had become so used to the same colorscheme that the colors themselves act as guideposts to navigate the code. Red for keywords--helps find the `else` block. Green for strings--easy to see the end of it. And so on. When I disabled syntax highlighting and looked at our codebase, it felt completely overwhelming and unfamiliar. I had lost my ability to read it efficiently. What followed was interesting--I had to read more intently, and in doing so I understood the code better. It took longer, but frequently the time was worth it. Over time, I adjusted and started to rely on different signposts--the structure of the code (whitespace, newlines, etc) proved much more important. I never got up to my full skimming speed though, possibly due to code styles that don't lend themselves to good visual structure (i.e. super long variable names causing wrapped lines). To my surprise, I actually really enjoyed programming without syntax highlighting. It made the little bits of color still there really stick out in a way that would otherwise get lost in the sea of color. Color became a much more intentional indicator, and things like blue for matching parenthesis and pink for compile errors stood out. I felt focused and I do think my code might have been slightly better structured. However, after a few weeks like this, I switched back because, as Cal put it, "we evolved to see color for a reason". I think there's definitely a scale of "useful color" and less is more in many cases, but being able to skim code is super powerful when on a timecrunch. Plus, it involves less explanation when I pop into a pairing session and share my screen :) ## Going All In: Bare Metal Install A month or so ago, still interested in the non-tooling bits of Plan 9, I decided it was time to give it a true install. I found an old SSD and put [9front](https://9front.org) on my X220 ThinkPad. I was greeted by the now familiar face of Acme, but a lot of other things about the system felt unfamiliar. For example, while in UNIX the shell has a bunch of complexity to handle line-editing, in Plan 9 this is all built into the windowing system. The window for the terminal allows editing any text, and that's the mechanism used to, say, rerun the previous command with changes. Likewise, there was no pager like `less` to capture and scroll in the terminal. Instead, the terminal doesn't scroll by default, so `man` just prints the whole manual and lets the user scroll. I didn't get to dive too deep into the actual distributed nature, since this was a single computer install. That said, I was left in awe by the realization that the original authors of UNIX had envisioned a different (and better in many ways) future. I find this so interesting because I think it's easy to put one's favorite technologies on a pedestal. But to see the original authors create something so different and imagine what could have been... It really drove home that there's a certain network effect for software. Once it's used it gets stuck. CLI tools for example-- `git` would take years to change `checkout` due to the number of scripts that use it. It made me wonder--what are the quirks of UNIX that we put up with as "the way things are"? How could it be better? Plan 9 was the closest look at the original authors' responses to these questions. ## Going Forward I'm writing this now on my OpenBSD install. I spent multiple evenings getting 9front to work and kept a somewhat detailed log that I've published on my gopherhole: [gopher://alexkarle.com/0/notes/plan9-journey.txt] Installing and perusing Plan 9 has changed the way I think about UNIX, mouses, and how I've idolized certain software. It's refreshing to peek into an alternate universe in which all things truly are files and resources can be distributed seamlessly across machines, but it's always nice to come home to the familiar.