the logic grimoire

Last night, I was thinking a little bit about the design of a FORTH-like “block editor” environment for Common Lisp. It would display fixed-size pages or “blocks” of code, which the user would navigate via: PageUp, PageDown, Home, End. There would also be a “dictionary” block which would display only function names in alphabetical order. (Really, set of blocks.) Perhaps it would be more fitting to call it the “Index”, like a book.

Something to figure out would be how to handle functions that are longer than a “page” or “block” in length. Since Lisp functions can be rather longer than FORTH word definitions, this could be an issue. Perhaps the block navigation keys only take you between blocks, and you always start at the top of the block, but the length of the block downwards depends on the length of the function.

Each block’s display shows the Lisp package its code is associated with. Just like Lisp code itself, every block must be associated with a package.

The Index contains not only all packages & functions defined by the user application, but also those of the Lisp system itself.

The user edits code by either 1) modifying existing blocks or 2) adding new blocks.

The block editor UX is monolithic to the user. It takes over the whole terminal and captures all keys. It is immersive. However, it is backed by a textual representation (that is, its state is textual) which can be checked into standard revision control systems. Because of this, it can be managed easily on standard UNIX systems. But once running, it has no knowledge of the operating system other than file I/O. Any OS interactions, network calls, etc., happen via the Lisp system.

The textual representation of block editor state is, at a high level, a “base plus incrementals” system. At time T, the user can say “save this state as name: XYZ” to create a base “image”. Then, during normal operation, every 5 seconds, an “incremental” state (diff on the base) is created.

Suggested keybindings:

• Ctrl-space : completion at point

• Ctrl-enter : evaluate enclosing expression

• Ctrl-. : view source of thing at point

• Ctrl-d : disassemble function at point

• Ctrl-t : trace function at point

• Ctrl-i : inspect thing at point

What follows is a lightly edited version of something I wrote at work re: AI assisted writing, how much of that we humans should inflict on each other, etc. (no work-related specifics are mentioned)
my standard is, if i’m putting it in front of a human to read, I’ve read every line myself, edited most of those lines, and done some structural edits too – the “shape” of AI writing is very common and well known by now. it’s very bland, for one. it’s also way too long and full of details, which is actually super bad for learning from. there should be fewer details and more overview/motivation in the start of most human-written design docs, etc IMO

as a reader, if i get the feeling a text is mostly AI-written I often disengage mentally pretty quickly. but it’s not boolean, it’s more fuzzy. if it’s clearly been edited quite a bit i might be able to hang, but if it’s just pure LLM, i feel kinda trolled tbh. it’s kinda like the “M&M color” musician contract rider thing, if i don’t feel the author has done work to see to those details i’m disinclined to spend time engaging much

as has been said a bunch by people whose work I respect, whatever we ship, we still own, AI or no. so our reputations are on the line. and i’d be worried about damage from shipping something to a colleague, customer, friend, etc that might show a lack of care for their time and attention

PS i used to work at a school for students with dyslexia and i know not everyone is as strong on reading/writing as they might like to be, so i also try to keep that in mind and be kind

On some random internet site, a person asked:

What is the probability of being dealt a bridge hand with 4 aces?

A mathematician named Douglas Zare gives the following answer (edited for formatting):

In a randomly shuffled deck, there are C(52,4) equally likely sets of locations of the aces. There are C(13, 4) ways those aces can be located in your hand. So, the probability that you get all 4 aces is C(13, 4)/C(52, 4) = 715/270725 = 0.264 %.

The other way Zare calculates this is:

• There are (combinations 52 4) ways the aces can be in the deck
• There are (combinations 13 4) ways the aces can be in your hand

Given the above, Zare then does the procedure that is also discussed in Hartshorn’s book Probability, which is: we divide the number of possibilities we care about by the total number of possibilities, namely

> (/ (combinations 13 4) (combinations 52 4))

which yields

11/4165
0.0026410564225690276

in other words, the same answer: 0.264%

Interesting observation when using my Scheme procedure LIST-PROBABILITIES.

> (exact->inexact (apply * (take (list-probabilities 52 13) 4)))
0.0026410564225690276

This gives the right answer as well, since it uses the alternative formulation of the problem, also suggested by Zare’s post linked above:

There are other ways to get the same answer. The probability that you get all aces is:

P ( A ) × P ( A ♡ | A ) × P ( A ♢ | A , A ♡ ) × P ( A | A , A ♡ , A ♢ )

= 13/52 x 12/51 x 11/50 x 10/49

= 0.00264 …

In addition, LIST-PROBABILITIES offers a roundabout way of calculating the same output as COMBINATIONS. Specifically,

> (/ 1 (apply * (list-probabilities 52 4)))
270725

is equal to

> (combinations 52 4)
270725

For some months now I have been working on my own take on the “terminal based coding agent”. It started out as a learning project, but has since progressed to the point where I use it every day for my professional work as well.

Unlike most other such recent programs like Claude Code, Codex CLI, etc. the program does not provide a Curses style user interface. Instead my inspiration is the interactive read eval print loop offered by programming languages such as Scheme and Common Lisp. More prosaically, it’s also similar to an interactive UNIX shell plus Lisp-style extension command. The entire “UI” (such as it is) is just text.

In general I find that the REPL metaphor, which is inherently language based, is more interesting and powerful than the “text user interface” (TUI) model which is much more limited. The latter brings to mind the green screen terminal programs which were historically used for data entry / form processing, and which guide the user through a more specific process or workflow that the software designer has prepared for them in advance. Although it can be very efficient for specific use cases, it removes flexibility and power from the end user in exchange for that.

Although it must be said in fairness that many of the modern terminal based coding agents also provide REPLs in the broader sense, I still don’t like the paradigm very much due to the intertwining of “user interface drawing boxes” and “interactive shell language” which in my view they conflate, to the detriment of both UI design and language design. For example, imagine that in order to use POSIX shell, you had to adopt some specific curses TUI with it? This conflation of concerns is a real design error IMO.

Another issue I have with the terminal based coding agents is that, having checked out the codebases and poked around a bit , many of them have a problem with Way Too Much Code ™ for my taste. When last I looked at Codex CLI, it had approximately 60,000 lines of code. I honestly don’t know what all that code is doing. No doubt it is serving some need that OpenAI has for the program in terms of enterprise integrations or features or whatever. But I am not really excited about running 60k lines of code (given the concomitant bugs to lines of code ratio that has been shown to be fairly constant over the years) in order to talk to some APIs and do a bit of processing on the output.

In general, when dealing with problems like this, I would much rather write my own smaller program that does just what I need and has UX that is to my taste. In this case in particular, it is a requirement that the UX be “text only” since I primarily live in and interact with the computer through Emacs (aside from the mandatory web browser). My experience has been that it is generally very easy to integrate things that speak plain text into Emacs in useful ways. I already have a “user interface” for any such program via an Emacs buffer that I control, so I have little interest in giving up that surface in exchange for some curses TUI someone else designed for their “average user”.

Further, years of experience interacting with various Lisp environments which has given me strong opinions about the overall UX I’d like, the types of “meta commands” that should be available, and how they should fit together in an integrated way. For example, I should be able to select any arbitrary text in any arbitrary buffer in Emacs and send it to the REPL subprocess for evaluation (whatever “evaluation” may mean in the context of that process)

I also want to be able to make a distinction in my work with the assistant between turn-based chat interactions vs explicitly asking for an agent loop to perform some task for me. There are times when I want more control over the interaction, and times when I want the assistant to “just do it for me”. As far as I can tell, tools like Codex and Claude Code assume that I always want the latter type of interaction.

From the above you can see that some of my primary requirements for SYNERGY were/are:

• plain text only for input/outout

• not too much code, small and hackable for my needs

• solid integration with Emacs (or Vim; I haven’t written that code but it should be easy for a Vimmer to write)

• provides UX reminiscent of Lisp REPLs, with useful set of “meta commands”

• makes a distinction between turn-based request/response interactions, and explicitly invoking agent loops

I’m writing about this here to share design ideas that may be interesting to someone in the context of REPL design. Nothing here is an original idea. These are all transparent rehashes of design ideas that have already been in use for a long time. Nonetheless I hope it’s useful to share them. I may write more about this in the future.

NB. There is a GitHub repo that I update sporadically in a “source code drop” fashion. It’s pretty much always out of date vs what I actually run. It’s not designed for anyone else to actually use, and I’m not really interested in contributions. What I am interested in is sharing some of the design ideas.

What follows is the current documentation taken from the SYNERGY source code as of 2026-01-24. It’s incomplete and also doesn’t explain everything as well as I’d like, but it’s a start.

From https://jem.fandom.com/wiki/Synergy

Synergy is a highly technologically advanced artificial intelligence. She can understand what others say and still have her own opinions.

Synergy is a REPL for talking to AI assistants. It is designed for both interactive and non-interactive use from the command line.

There are two “modes” for interacting with Synergy: interactive mode, which provides a REPL; and non-interactive mode, which is when you’re talking to Synergy over a pipe.

If you go to the Terminal and start synergy, a prompt appears. You can type questions at the prompt, and they will be sent to the AI assistant. The assistant’s responses will be printed out. For example:


$ synergy
USER > i am writing perl documentation in the POD format (a README), how do i represent a quotation / blockquote?
(1741177286.90149) thinking ...
In Perl's POD (Plain Old Documentation) format, you can represent a quotation or blockquote using the `=begin` and `=end` blocks with the `text` format. Here's an example: ...


Synergy also accepts special commands starting with a comma. These commands are not sent to the AI assistant. Instead, they control the state of the REPL. For example, you can add a text file into the context of the current conversation, or print out the estimated number of tokens used so far.

When you add a file to the context, it is stored in a stack. There are several stack manipulation commands for pushing, popping, rotating, etc.

The simplest way to talk to Synergy is via one-shot commands over a pipe


$ echo "Please write a haiku in the style of Li Po about what it's like to be an artificial intelligence" | synergy
Here's a haiku in the style of Li Po, capturing the essence of an AI's experience:

Moonlight of data
Flowing through circuits of thought
No heart, yet I dream


The complete list of special commands is documented in the interactive help output.

$ synergy
USER > ,help
This is Synergy. You are interacting with the command processor.

A command is either a prose form for the Assistant to evaluate or one of the following:

,help ,? Print this help message

,history Print out the conversation history so far

,reset [N] Discard conversation history (A B C - )

- With no args: discard entire history

- With arg N: reset history to position N

,collect Replace current conversation history with a summary

,s Print contents of file context stack

,push file.txt Push file.txt onto file context stack (B C - A B C)

,swap Swap top two elements of file context stack (A B - B A)

,rot Rotate file context stack entries (A B C - B C A)

,drop [N...] Remove elements of file context stack:

- With no args: pop top stack element (A B C - B C)

- With arg N: remove element at index N (A B .. N - A B ..)

,peek N View contents of Nth element of file context stack

,dump file.xml Save session history (including current file context stack, if any) to disk

,load file.xml Load session history (including file context stack, if any) from disk

,pwd Print current working directory

,cd /some/dir Change working directory to /some/dir

,exec cmd Execute shell command (grep sed wc ls file find cat make head)

Output is saved to conversation history

,apply_patch file.txt {PATCH}

Apply patch in diff-fenced edit format to file.txt

,comment Write a comment that is printed back to the REPL's output.

This is useful for notes to self by humans or AI agents.

,model [name] Print (or switch) the current model

- With no args: Print the current model and the list of options

- With name (e.g., `gpt-5`): Switch to model with that name

,encoded Base64 encode contents of API calls to the Assistant (default ON)

,exit Quit the SYNERGY command processor

Finally, there is an agent command that takes as its argument a sentence that describes a task for the agent to complete autonomously using a subset of the commands listed above.

The synergy program is written in Perl, and uses a number of libraries that need to be installed. For now, see the source code for details.

You will need to provide an API key:


$ export LANGERTHA_ANTHROPIC_API_KEY="ABC123..."


There is a file inf-synergy.el in this directory that provides some niceties for interacting with Synergy from Emacs, including:

• M-x run-synergy: Start or switch to a Synergy chat buffer.

• C-x C-a y: Quick shortcut to create or switch to Synergy buffer.

Once in the REPL, the following features are available:

• C-c C-n: Move forward through commands.

• C-c C-p: Move backward through commands.

• S-return: Insert newline without sending input.

• RET: Send input to Synergy.

Note that the Synergy REPL will highlight any single-line inputs to the REPL that are longer than 999 characters in bright red starting at the 1000th character.

This is necessary because the maximum length of string a comint-based REPL will accept without hanging with ‘^G’ (control-G) characters is 1005 based on my testing. (This applies to both older and more recent Emacs versions, and seems to be controlled by the process interaction layer at the C code level and not user-configurable.)

• M-x synergy-push: Pushes files to Synergy’s file context stack. Pushes current region if a region is selected. If no region is selected, pushes the entire buffer. In Dired mode, pushes marked files or just the file at point if nothing is marked.

• C-x M-w: Copy code block from Markdown-formatted text.

Credit for the design goes to:

• Scheme48: The command processor “look and feel”, as well as the special command syntax and help output, are directly taken from Scheme48.

• Forth: The file context stack manipulation commands are inspired by the Forth programming language.

Modern “educated” people are very strange, and we have many failure modes that are particular to our era.

One failure mode I have been thinking of lately is that we jump far too quickly from “I have observed some particular phenomenon” to “here is an abstraction that explains this phenomenon and others like it”. These explanations are almost always wrong of course because we’re human

I feel like the modern education system does too much of showing people that the process of mapping groups of phenomena to some single explanatory abstraction is “the way to think about things” – however, in practice the average level of this type of education generally only shows the end product of many years of intellectual struggle without doing enough to describe the process that led to the currently accepted abstractions, including most importantly all the many wrong turns along the way.

This phenomenon I’m describing (ha, I know right, this is just my version of an incorrect unifying abstraction eh?) can be seen in having students factor a bunch of polynomials after showing them a few, maybe with a little chat about “here’s a polynomial”, but not actually walking them through the observations and activities that led long ago mathematicians to discover polynomials among all the possible mathematical objects they could have cared about then or now (which are approximately infinite). Similarly, once those old people found them and wanted to use them, there was probably a process of figuring out “how the heck do we work with these things” or “what does this actually mean” that is generally elided in favor of some current mechanistic “here’s what they mean, here’s how you solve them” abstraction process given to the students.

Similar effects occur in the humanities, where people at the age of 20, who know basically nothing about life, learn about some dead intellectual’s pet theory and then proceed to apply that theory to explain various human behaviors at the micro or macro levels. Many books are read, and many pages of “reactions” to those books are written. In fact, the reactions must be written, on demand and to a deadline.

And above all, the holy commandment: you must react. The worst possible thing you can do as a student is not react quickly enough to the stimulus of the equation being presented to you and thus be unable to decide “what it is” and choose the right method of solving it, or not have an opinion quickly enough on some block of philosophical text such that you can compose the required essay for teacher on a deadline. If you are too slow on the uptake and cannot immediately “stand and deliver” as this process requires, you will not succeed in our education system.

(These specific examples are probably bad but I think they’re directionally correct)

Unfortunately I don’t think this is a very good way to learn how to think, how to react to things that happen, or how to process information. It’s especially not a great way for the average person to go through life who does not have an above average IQ (which is most of us). And based on the evidence of experience I’m not convinced it’s working that well for the smarties, either. They’re usually wrong too, just in more interesting and/or horrific ways.

I’m sure others have written more intelligently about this.

• 30 blog posts published
• Publish my book Invitation to Algorithms with Scheme (Finish writing it first!)
• Finish working through Kordemsky’s Moscow Puzzles book
• Learn to design furniture in CAD (SketchUp?)
• Build a (scale model) Fiddlehead canoe (using Harry Bryan’s plans)
• Build kitchen shoe rack
• Build office bookcases
• Build kitchen pantry
• Get desk, bandsaw, etc. from storage
• Organize shed
• Redesign my office (renovate?)
• Ride 2026 Shawangunk Grit
• Ride with Fats in the Cats MTB club
• Ride with my friend Jesse in Zwift this winter
• Build a bathroom cabinet
• Start work on my next book A Handbook of Graph Algorithms
• Walk 10k steps a day, most days
• Get hunting license
• Get fishing license
• Catalog ALL of my books!! (Using Dewey?)
• Visit Nate
• Visit Justin
• Finish reading Stirzaker’s Probability and Random Variables: a beginner’s guide
• Finish Raschka’s Build a Large Language Model from Scratch
• Write “morning pages” almost every day
• Various other private things which I shall not utter here

I would still like to write my own constraint programming (CP) solver. Yes, likely in Perl, though over time we could consider adapting the core to portable C for re-use in different contexts. Similar to my YAGL library, it shall have a comprehensive (as I can make it) test suite, with lots of examples pulled from all around the internet (and properly cited).

In terms of design, I did not entirely love the Java constraint solver community specification (JSR-223, I think). Its API was rather “stringy”, with things like new Var(“x”). Although perhaps with more study I’d come to appreciate it more. I can also imagine something along the lines of the following rough sketch:

my $solver = Solver->new;
my ($a, $b) = (Solver::Var->new, Solver::Var->new);
$solver->add_variables($a, $b);
$solver->add_constraint( sub { $a + $b == 7 } ); # still fuzzy!
@sols = $solver->solve;
say @sols; # [[0,7], [1,6], …]

I like the idea of each constraint being expressed as a lambda function, that is then used as one of the predicate checks during the internal search. The search could be a graph search that uses YAGL (or alternatively, Graph.pm) internally. There is the obvious problem that exhaustive search of a graph has bad performance as the graph grows large (and in fact may be NP-hard or NP-complete, although I’m fuzzy on the difference without looking it up).

I already have some (IMO confusing, object-oriented) Python code for a basic constraint solver from the book Classic Computer Science Problems in Python (aka [Kopec 2019]) which I may be able to use as a starting point, at least conceptually. (It’s quite a good book, by the way!)

There is of course a vast literature on constraint programming. I have the classic Programming with Constraints by Marriott and Stuckey here (aka [MarStu98]), and this project will motivate me to finally read it, I hope. From an earlier skim I seem to recall that there is a bit about constraint graphs, and some very Prolog-adjacent bits as well. Some Prolog-esque code snippets sprinkled through-out, but not enough to write your own solver with. Still, I’m sure it will be a good starting point.

What follows are some raw notes taken during a workshop with James Nestor called “The Power of Breath”, held the weekend of October 3-5, 2025 at the Omega Institute. Any errors or misrepresentations in these notes are mine.

Mr Nestor and team who conducted the workshop (including Emma Estrela) did an exemplary job and I’d highly recommend it to anyone who has the chance to attend. They don’t do workshops very often, though, so the next best thing is to check out his book Breath: the new science of a lost art

FRIDAY:
* proper biomechanics
* “you’re breathing wrong”
* World Freediving Championship
* L 330 ft., 4 minutes
* swam with dolphins, whales
* How you breathe at night can affect if you later have diabetes
* Paris skulls in catacombs
* Morton Center at UPenn (skulls)
* We have crooked teeth because our mouths are too small.
* Animal teeth are straight, so are prehistoric human teeth

3 principles: (also Wim Hof method)
* Breathe Deep
* Breathe Nasally
* Hum.
* Biomechanics method

Benefits:
* improves digestion
* relaxation
* removes toxins
* balances blood pressure
* Peak lung function is late 30s
* Learn to breathe properly all the time.
* Emphysema can be rehabbed w/ breathing techniques.
* Straighten scoliotic spines with stretching & breathing.
* Alternate nostril breathing
* R: activates
* L: calms
* Nasal cycle: switches sides

• Nasal benefits:
• more O2
• better memory
• emotional regulation.
• “Adenoid face” caused by mouth breathing by kids.
• 50% of kids 2-5 have sleep problems.
• 70% of people with ADHD also have disordered sleeping
• George Catlin: “Shut up” (book)
• Stanford – Nayak research Lab
• Nasal breathing therapies:
• Surgery (risk: empty nose syndrome)
• open nostrils (breathe right)
• neti pot
• “mute inserts”
• exercises
• mouth tape
• 30% increase in use for exercise with nasal breathing

Mouth taping tips: “General Guide”
* 10 mins. awake
* 20 m awake
* 60 m awake
* …and so on…
* 3M micropore sensitive skin tape is Nestor’s choice
* What is the sleep app?
* Snorelab – records sound of your breathing at night.
* Shoreclock – your breathing at night.
* Hum breathing benefits:
* more nitric oxide, melatonin
* stimulates vagus nerve

SATURDAY: Emma Estrela
* Geshe Yong Dong – Tibetan.
* Exhale helps downregulation on table
* Exhale 1…10 x 10 saying “1-10” out loud

• What changes breath:
• biochemistry
• emotional
• biomechanical
• We’re focused on the BIOMECHANICS
• Best way to change is: then other two follow
• other influence: Wim Hof changed limiting beliefs
• Paradoxical breathers: backwards breathing (belly in, chest out) – THIS IS BAD

3 pillars (Wim Hof method):
* breathing
* cold exposure
* mindset

Emma: Cumbria, Lake District
* Wim Hof instructor
* 6 diaphragm breathing exercises (based on yoga)
* Trained for marathon with:
* Wim Hof breathing
* cold exposure
* 3M micropore sensitive skin tape!
* Exercises: cat cow
* imaginary candle
* 1-10 on fingers, exhale
* back breath (child pose) Big}

Carl Stout , 1950s, see Nestor’s book for info

• “Breathe Light” 4-7-8 to sleep (on airplanes, etc..).

Lecture: Ancient Chinese & Qi Gong

• Posture is huge in ancient China
• Tao Te Ching on posture & breath
• Head weight: 12 lbs. if standing straight
• 32 lbs. if slouching, neck forward
• Tao breathing advice: “SLOW”
• • slow
• • long
• • deep
• • fine (smooth & quiet)
• • tranquil (& even)
• Heart math HRV test (Heart Rate Variability)
• Richard Brown, MD – Columbia. Psychiatrist
• Slow breathing benefits:
• • memory
• • better decisions
• • reduce anxiety
• Led breath exercises with anxiety patients.

sports
* Brian McKenzie, trainer
* starts with breath exhale test; 1-10 (I got a 5) NOT strength, speed, etc.
* desired: 8-10

“Coherent breathing”: Ancient Chinese
* 5-6s in, 5-6s out
* 1200 yrs. old: “lie down, block the breath… exhale through mouth… finely. Count 100 with blocked breath, then exhale” (paraphrased)
* This is also the “Wim Hof method”
* Breath retention benefits:
* * red blood cells
* * blood vessels.
* * release nitric oxide (NO)
* * release more Human Growth Hormone
* Bodhiharma went to Shao Lin
* Cultural Revolution outlawed Shao Lin breath practices
* CIA study: project energy from hand to LCD screen
* PBS “The Ring of Fire”
* “Six Exhalations of the Tao.”
* Robert Peng
* Nestor met Peng, had lunch (did not expect to see him)
* HSU / liver (6) “shhhhh” green
* HO / heart (6) “haaaa” red
* HSI / Lungs (6) “ssss” inner leak
* CH’UI / kidneys “sh-hee” (white)
* HU / SPLEEN. “hoooo” dk. blue
* TRIPLE BURNER “seee” yellow (no color)

Breathworkers
* Emma (UK)
* Anna: (VERMONT)
* Irene: (Long Island)

SUNDAY:

“Coherent Breathing”
2-4 “in”

4 “out”.
Breathe in: 4 steps 4″in”-8″out”** “Light”
Exhale: 4 steps > while walking

• Q: Daily practice you recommend?
• A: Find what works for you:
• Qi Gong
• Holotropic
• Wim Hof (Buteyko?)
• Most important to breathe normally
• Nestor has breathwork audio recordings, will be free on web in about 1.5 mos.

REVIEW:
* Youtube “nose unblocking exercise” McKeown, Patrick (4M views)
* Myo tape (the mouth) Sleep tape
* Hum 4x daily 10m for sinusitis
* rock and roll (tilt hips back & forth)
* cat and cow (5 good ones)
* back breathing (child pose)
* blowing candle (anger mgmt.)
* seated twist, (like yoga) grab opposite leg.
* alligator breath – lie on belly, weight of body. lift up on inhale.
* Good before dynamic breathwork.

BON and TUMMO:
* Bon buddhism (18k years).
* air/breath/energy = lung
* oldest breathing modality in the world
* 21,600 breaths a day: 10,800 in, 10,800 out
* 7.5 breaths/min
* “Coherent breathing”
* 1959: Chinese destroy 6k monasteries, kill 500k people.
* Snellgrove, The Nine Ways of Bon
* Tummo: breathe to create heat
* Herbert Benson @ Harvard Med.
* wet sheets on monks.
* Bon Mantras (Humming)
* Robert Peng: it’s just the vibration don’t worry about the meaning
* “AH, OM, DZUN, MAN, ZA …”
* Tokyosound artist using sand on metal table (video)
* Wim Hof method cycle (from memory):
* 30 or so breaths at some tempo
* Inhale, exhale “blow candle”, HOLD
* Normal inhale & exhale
* Inhale “all the way up”, HOLD
* GOTO 1. (4 rounds total)
* Led by Emma. See [Nestor 2020] p. 156 for description of technique.

Nestor2020

Over at https://news.ycombinator.com/item?id=45839299 someone posted about some nice workflows they’ve set up as part of trying to live as much of their computer life as possible in Emacs

The discussion thread has a lot of talk about specific features, Org mode, how to learn Emacs, etc. a lot of which I felt was kinda missing the main point, which is complete programmability and freedom with regards to anything producing text on your computer. Packages and features are mere ephemeral phenomena and ultimately irrelevant over the long term

Anyway here is what I wrote:

This is a very good feature/workflow based intro

As the years go by one realizes that even these “features” like Org, Dired, etc are just illusions in some sense. They’re just Elisp code someone else wrote and put a name on. You can take or leave them or write your own code that changes/advises/customizes them.

It’s all up to you. You don’t need a blessed “plugin” architecture, some PM at IntelliJ’s permission etc

At some point one realizes the “visual shell” nature of Emacs. Every single piece of text on screen can be programmed to “mean something” (see also: “recognizers” from human interface research) and have actions taken on it either by the editor itself, or external processes / scripts you call with a command. If it’s common enough, make a key binding. It’s your house, do what you want

Depending on how you set up your environment, you may never have to look at text again that you do not have this level of power over. You are no longer at the mercy of “application developers”

I’ve been using it since 2005. Guess how many of 2005’s popular editors even still exist

My recommendation to anyone trying to actually learn is start with the full vanilla config, weird default keybindings, etc, go through the built in tutorials, and only add things to your config that you write and understand yourself. Understand it in its own terms. The plethora of packages, etc have “cool features” but impede learning by adding mountains of complex dependencies that are opaque to the beginner and cause confusion IMO

I’m trying to set up a personal computing environment that I can rely on for the rest of my life. I told Justin that when we chatted recently, and I realize that I meant it. But what does that mean, exactly?

I don’t know, in an exact sense. But broadly, it means that I need a standard set of tools that I can rely upon. Even my beloved Emacs is getting changed out from under me by these fricking children. I will need to figure out how to build a version of Emacs that is roughly equivalent to what I have now, in perpetuity. (Currently I mostly use Aquamacs, which is based on Emacs 25.3. But it’s an ARM build, and runs on Rosetta so its days are numbered.)

They are also changing my beloved Perl. Removing things I rely on, such as smartmatch and soon GOTO, and adding weird syntax. They have no business doing language design. Maintainers should maintain code. Few understand this.

Common Lisp is out there. If I write code that, it will never break. As long as I never use any runtime-specific extensions, that is. It’s a viable option. I wonder how much of my Perl code I could reimplement in CL. Probably most of it. Tim Daly’s talk on Literate Programming said to (basically): “write code in Common Lisp; build with make; write docs with LaTeX.” Timeless wisdom. But I have not (yet) heeded it. Why not?

There’s a feeling that, at some point, I’m going to have to bite the bullet and learn C. Emacs and Perl are written in C. The OSes are as well. Smalltalk, underneath. Basically everything, underneath. Even the vaunted Common Lisp implementations are riding on a lot of C code.

Another idea I had, in the age of AI, is to write my own language implementation, and to use that for everything. For example, I don’t love the complexity of CL. And I don’t fully trust the Emacs and Perl maintainers. But what if I wrote my own Scheme subset that does just what I need? Or my own Perl subset that runs the code I care about?

Another idea is to join in & become one of the Perl helpers. Another is build Budd’s Smalltalk and add scripting capabilities and just go off and live in that world. The possibilities are endless.