After I re-read [Peter Naur's "Programming as theory building"](https://gist.github.com/onlurking/fc5c81d18cfce9ff81bc968a7f342fb1) I set out to write my own [text editor](https://texteditors.org/cgi-bin/wiki.pl). 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 while I read was that our primary programming medium -- text files -- is silly. Like, some folks would totally 100% scoff at me writing [forth](/forth) but, at the end of the day, forth and javascript each produce executable text files. What if a text editor let us have something more than just that 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 number 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 around 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](https://billmill.org) 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](https://git.sr.ht/~eli_oat/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 projects. Moons are files that orbit a planet, places to take notes, scratch space, somewhere to try things out, or add layers of information. 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. 

```plaintext
    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 an 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 you need them. 

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 tools, and moons in another. 

I don't honestly expect many or any folks to use this tool, 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 `.tmp` or scratch files to document little corners of something, and experiment. This enables that in a sort of consistent way across projects while working with all of my existing tooling.