« Oatmeal

I recently re-read Peter Naur’s “Programming as theory building”. Afterwards I set out to write my own text editor. The paper posits that it’s really hard, if not impossible, to fully communicate about a program and sort of gestures at the futility of documentation…what spun around inside my head as I read was that our primary programming medium — text files — is silly. Like, some folks would totally 100% scoff at my writing forth but, at the end of the day, forth and javascript both produce executable text files despite being lightyears apart. What if a text editor let us have something more than just text files as artifact?

So, like many before me, I started to write my own text editor. And it sucked. What I made sucked, and the process itself sucked…or, at least, it didn’t lead to anything particularly different from the vast array of existing text editors. I wanted to be able to support a different paradigm of writing code, I didn’t wanna just produce vim with worse ergonomics. I didn’t make much progress, even leveraging web technologies that gave me a lot “for free,” because before I could begin to reinvent any particular wheel I had to crawl out of the primordial ooze…

Then I realized I didn’t actually want to implement my own text editor! I’m not a fanatic about what editor I use; I’m pretty evenly split between sublime text, emacs, text edit, vim, acme, and mg. I bounce between them depending on what I’m doing, and for how long I’ll be doing it. What I wanted was to be able to support a slightly different mental model of what a “file” is using any existing editor!

That was an easier technical nut to crack. It took about 2 hours after the kids went to bed with a little bit of help from the inimitable llimllib on mastodon…and all I did was write a shell script!?

So, my personal solution to the cutting edge of programming being just text files is to add even more text files!…at the end of the day, they’re a really really hard thing to leave behind, especially if you’d like to preserve compatibility with any existing programming system.

I wrote a shell script called Moon Maker. Moon maker, or mm, lets you attach orbiting moon files to central planet files. A planet file is the one you really actually care about — its probably a file in a project. A project can have any number of planet files, and a planet file can have any number of moons in orbit of it. Moons are files that orbit a planet, they’re places to take notes, a scratch space, somewhere to try things out, or add layers of information about the planet. A moon file can have any file extension, and references the planet by it’s name. Moon files live in a directory of their own, .moons, and each can be referenced by a unique id, or, collectively by the name of the planet they orbit.

    Moon Maker

    ⋆｡°✩ ☾

    mm is a small program that lets you add orbiting moons to existing planets.

    A planet file is the one you care about -- probably a file in an actual project.
    Moon files orbit planets, they are disposable scratch spaces connected to planets.

    usage: ./mm
                    -i(nit)....initialize a directory to store moon files
                    -o(pen)....open a planet file and all of its moon files
                    -l(ist)....list all moons for a given planet file
                    -a(dd).....create a new moon file for a given planet file
                    -d(elete)..remove a moon file by its id
                    -c(lear)...remove all moon files for a given planet file
                    -u(pdate)..rename a planet file and all of its moon files

The idea is you use mm sort of like you’d use git — you initialize it at the project level, and then add moons to planets as needed within the context of a project.

By default, moons open in your EDITOR of choice, but I’m thinking of adding support for editor overrides so you can easily open planets in one tool, and moons in another.

I don’t honestly expect many or any folks to use this thing, but I’m excited too. It matches my mental model, and, my process: usually, when I’m working on a project, I end up creating a bunch of temporary or scratch files to document little corners of something, and experiment. This enables that in a consistent way across my projects while maintaining compatibility with all of my existing tools. If this works out, and doesn’t have any toothy gotchyas I’d like to support adding moons, satellites maybe, to specific lines, or regions of a planet file, too. My first attempt at this thing was more elaborate — rather than bash and saving to the file system, I tried to do something with sqlite, and having a database backing each file of a project.

The idea was to support using any convergence of row and column number of a text file as an id, and then generate a connected moon from that. This was a cool idea, but so fragile as to be untenable. Plaintext doesn’t offer a great way to reference specific points in a file if that file is changing.