NO_COLORPublished: 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.
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 (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 (a userspace port of many Plan 9 programs) and tried to integrate it into my workflow.
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.
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:
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
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.
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 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
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 :)
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 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.
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.