diff options
author | elioat <elioat@tilde.institute> | 2023-02-18 08:49:42 -0500 |
---|---|---|
committer | elioat <elioat@tilde.institute> | 2023-02-18 08:49:42 -0500 |
commit | 22798d2fde16c47e11fd4df32433f21d71872f7d (patch) | |
tree | 5fd4fc489fcf7cb5ad2c1c344217437fc3313841 | |
parent | adf69cfa110088bb3d366683ccd105a5807edf23 (diff) | |
download | tour-22798d2fde16c47e11fd4df32433f21d71872f7d.tar.gz |
*
-rw-r--r-- | bash/moon-maker/borb.md | 37 | ||||
-rw-r--r-- | bash/moon-maker/earth-rise.png | bin | 0 -> 20704 bytes |
2 files changed, 37 insertions, 0 deletions
diff --git a/bash/moon-maker/borb.md b/bash/moon-maker/borb.md new file mode 100644 index 0000000..a225f30 --- /dev/null +++ b/bash/moon-maker/borb.md @@ -0,0 +1,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." 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. \ No newline at end of file diff --git a/bash/moon-maker/earth-rise.png b/bash/moon-maker/earth-rise.png new file mode 100644 index 0000000..a869c87 --- /dev/null +++ b/bash/moon-maker/earth-rise.png Binary files differ |