1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
|
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.
|