Remove redundant return value from _cmd_set_boolean_preference - profani-tty

diff options

author	James Booth <boothj5@gmail.com>	2016-04-17 23:46:29 +0100
committer	James Booth <boothj5@gmail.com>	2016-04-17 23:46:29 +0100
commit	153552ed074d0890e9ccbb3618a9c44309d7ff65 (patch)
tree	2028837b7623f67e2bcd7cab48b20fe321c062df /src/common.c
parent	2daa02cb60fc27e4dddadc32e487088c38b97b02 (diff)
download	profani-tty-153552ed074d0890e9ccbb3618a9c44309d7ff65.tar.gz

Remove redundant return value from _cmd_set_boolean_preference

Diffstat (limited to 'src/common.c')

0 files changed, 0 insertions, 0 deletions

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.


context:
space:
mode: