On ZIL indentation
Sunday, July 12, 2026 (updated 1 day later)
Comments: 11 (plus live) (latest 5 days later)
Tagged: if, interactive fiction, infocom, zil
I tried to give this post an eye-catching title like "The Power of Indentation!" But my fingers wouldn't have it. Blame the fingers.
I don't know much about the text-editing tools used at Infocom. The Witness source directory includes a tantalizing mention of TECO, an editor used at MIT in the 1960s and 70s. Going back a couple of years, there's a map file in the 1978 MDL Zork repository which seems to about managing TECO keybindings.
TECO's editing macros later evolved into their own editor, naturally called "Emacs". Wikipedia notes:
By 1979, Emacs was the main editor used in MIT's AI lab and its Laboratory for Computer Science.
It seems certain that Infocom folks used Emacs at some point, but I don't have any evidence about when.
Whatever editor they used, we can ask: Did it auto-indent their ZIL code? The ZIL code we have is very consistently indented, so it seems like a good bet, but I don't know for sure. The only reference in the 1989 ZIL manual is:
Also note the spaces at the beginning of the TELLs in the DESCFCN. If your describers are of the indentation flavor, your DESCFCN must supply its own indentation.
"Describers" are explained as:
[...] a small package of programs which handle the descriptions for the player's environment: current room and visible objects.
...Which is interesting, not least for saying "programs" for what we (and ZIL itself!) call "routines". I think that "indentation flavor" is not about source code indentation, but rather the indented style of object listing:
Sitting on the kitchen table is:
A brown sack
The brown sack contains:
A glass bottle
The glass bottle contains:
A quantity of water
A clove of garlic
Some Infocom games used a more sentence-like listing format, particular if they were less container-heavy.
But I digress. Let's go back to the source code.
This is what the Infocom devs saw as they wrote their code:
FIND-IN, from Zork 1.
(But probably in black and white. Or black and green. The syntax coloring is my addition.)
ZIL, like Lisp, is built around deeply-nested lists. Indentation is purely decorative, but it's a huge part of making ZIL/Lisp code readable. You can see that function above is indented to indicate nesting and what lines up with what:
The same function showing alignment guides.
As I said, this is very consistent through all the ZIL code I've looked at. The only exceptions are long spans of text, which are left-justified for readability:
DAM-FUNCTION, from Zork 1.
This indentation style seems to be designed specifically for ZIL game code. The ZIL compiler (which is MDL code, same idea) has similar code indentation; but multiline text spans are handled quite differently. So my guess is that someone built an indentation routine (or "program"!) specifically for Infocom game source.
That's all great. Unfortunately, when I launched the Visible Zorker, it rather mangled the indentation.
FIND-IN as shown in the original Visible Zorker. Some of the vertical alignment is wrong.
That's entirely my fault. The original source files were indented with tab characters, and assumed 8-column tab stops. A very classic format, to be sure. But I'm used to 2-col or 4-col tab stops. When I wrote my ZIL-display code, I told it to transform tabs into four-space sequences.
When I made that decision, my only thought was, "It'll take up less space that way." The Visible Zorker app is divided into two or three text columns. They can be awfully narrow. Anything that reduced horizontal whitespace seemed like a good idea. But as you see, the vertical alignment went completely flop-bott.
Someone pointed this out on the forum last week (thanks squam!) I cranked on some reindentation logic, and eventually settled on this:
FIND-IN as shown in the Visible Zorker today.
It's roughly the same as Infocom's style, except that the first level of indentation is always two columns. (Rather than trying to line up with the routine name.) This saves some space while keeping everything else aligned. It's particularly good for object definitions:
The SWORD definition in Zork 1.
For large functions it can be wider than my previous (four-space) code. But I think the improved clarity is worth it.
All the Visible Zorker games have now been updated with the new format. Let me know if you see any problems.
(This article is cross-posted to my Patreon.)
Addendum:
Hey, look -- evidence of editing software revealed! See video and comments below.
From a BBC documentary segment about Infocom.
(The video is from 1985 and shows the development of Spellbreaker. So a bit later than I've got to in my Visible Zorker timeline.)
Comments from Mastodon
@ori I love that all the Spellbreaker bug reports are titled "MAGE" on the report form.
I still can't pin down what editor we're looking at, though.
@zarfeblong @ori The "Select Buffer" commands ending with a $ suggests TECO heritage
@ankrmu @ori Oh, interesting, thanks.
I never used TECO. All the screenshots that I can find online have the name "TECO" in the status line, which is distinctive; but I don't think any of them date back that far.
@ankrmu @zarfeblong @ori The editor is RMODE, which is implemented on top of TECO. It's running on Infocom's TOPS-20 computer called FRED, displaying on a VT100.
In a sense, RMODE was an older sibling of EMACS. EMACS became the more popular editor and some features from RMODE was moved into EMACS.
@ankrmu @zarfeblong @ori Even before Infocom was founded, the Zork people - part of the Dynamic Modeling group at MIT - used TECO and RMODE running on ITS.
@ankrmu @zarfeblong @ori Did RMODE support automatic indentaiton for ZIL code? I haven't checked, but I would believe so. Both RMODE and EMACS have editing modes for Muddle aka MDL, and I think the syntax is essentially the same as ZIL.
@zarfeblong Another possible clue to which editor they - or at least someone - may have used is in the corrupted globals.zil from enchanter-mac-r16.
Though I couldn't say for sure that this is output from an editor somehow making its way into the text.
@et_andersson I figure that’s a sector from a random emacs doc file elsewhere on the disk. Could have happened any time the machine was running, or when the drive was mounted later for recovery.
@zarfeblong Maybe. At least someone appears to have used something emacs-like in the general vicinity of that file.
There are a couple of other corruptions in it, e.g. "alresey" instead of "already" and "GR?" insead of "CR>" (single bits being flipped somehow?) so it appears to be a bit cursed.
Comments from Mastodon (live)
Please wait...
This comment thread exists on Mastodon. (Why is this?) To reply, paste this URL into your Mastodon search bar:



@zarfeblong This 1985 video shows an editing operation where an ELSE is moved outside of a COND and it reflows https://youtu.be/qXAubRZ-qjw?t=141