about summary refs log tree commit diff stats
path: root/bash
diff options
context:
space:
mode:
authorelioat <elioat@tilde.institute>2023-02-18 08:49:42 -0500
committerelioat <elioat@tilde.institute>2023-02-18 08:49:42 -0500
commit22798d2fde16c47e11fd4df32433f21d71872f7d (patch)
tree5fd4fc489fcf7cb5ad2c1c344217437fc3313841 /bash
parentadf69cfa110088bb3d366683ccd105a5807edf23 (diff)
downloadtour-22798d2fde16c47e11fd4df32433f21d71872f7d.tar.gz
*
Diffstat (limited to 'bash')
-rw-r--r--bash/moon-maker/borb.md37
-rw-r--r--bash/moon-maker/earth-rise.pngbin0 -> 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