Emacs IBIS Mode
Uhhh this might just be a public letter to @Andy ![]()
So I tried to use a minimal notation from the IBIS Field Guide (PDF Link) and the bis vocabulary
Here's an example (machine translated from German):
? I-1: How should conditions and deadlines be made clear?
→ Rename existing forms only
- Does not clarify prerequisites or what happens when they fail.
→ Manage state conditions and automatic deadlines separately
+ A deadline can expire while later player actions remain possible.
? I-2: Do pages need to become executable code?
→ Data forms create observers and timers #test
+ Dependencies and writes remain visible.
→ Constrained factories create the same data #test
+ Helpers and a REPL, without arbitrary runtime callbacks.
→ Arbitrary runtime callbacks
+ Flexible composition.
- Hidden dependencies, side effects, and closure state.
? I-3: What should Tangle do?
→ Collect data forms in one file
+ One artifact; execution stays with the interpreter.
→ Generate an executable entry point with a controlled context
+ Build and inspect it in the REPL.
- Requires bindings, quoting, or macros; `eval` alone is not enough.
The Field guide doesn't prefix the issues. I prefix with ? for parsing. The Field Guide doesn't recognize hashtags, but I parse them here to group and filter things. That's just a text convention and doesn't "break" anything.
Looks like this rendered in modus-themes in Emacs:

So far so colorful; you get a couple of actions to insert pros/cons and move things around in the outline; M-<up> on an issue will move (aka 'transpose') the whole issue tree, not just the line. So you have outline style editing.
I'm using this mode mostly to read and edit things that AI agents generate in this format to keep divergence in mind.
It's a test drive and I can't say what benefit or harm it brings.
Source available here:
https://github.com/ChristianTietze/ibis.el
Note on AI use: I handed of implementation to Claude Code and reviewed the UX.
Author at Zettelkasten.de • https://christiantietze.de/
Howdy, Stranger!
Categories
- 3K All Categories
- 153 Research & Reading
- 702 The Zettelkasten Method
- 12 Knowledge Work
- 101 Writing
- 473 Software & Gadgets
- 157 Workflows
- 733 The Archive
- 15 Plug-In Showcase
- 88 Resolved Issues
- 225 Projects Logs and Journals
- 86 Project: Zettelkasten.de
- 53 Critique my Zettel
- 177 Random
- 375 Introduce Yourselves!
Comments
By the way, what's "Sleeper Effect" but you actually remember who's the culprit
https://en.wikipedia.org/wiki/Sleeper_effect
Author at Zettelkasten.de • https://christiantietze.de/
I'm very happy to see this, as you could imagine.
I don't use Emacs, but I am curious enough that I will look at the Lisp source code for this.
I see that most of the commits on GitHub are attributed to Claude Code, which is very interesting. I've never seen that before, but I guess it has been a long time since I've looked at other people's git commit histories.
@Andy I'm very anal about my personal project git history, and when I let the agents work for a while, I let them commit, so I know what I really really touched and what I didn't.
The implementation was trivial because the specs exist already; I just don't know whether any external format is used by IBIS fans to express semantic relations
Author at Zettelkasten.de • https://christiantietze.de/
I don't know of any standard data exchange format for IBIS, which is a general approach that tends to be customized in particular implementations. Even Dorian Taylor thinks about IBIS a bit differently than I do, and I wouldn't use his vocabulary for my own purposes. The variability of argumentation/discourse schemas like IBIS is why the people at discoursegraphs.com felt the need for their standard as an exchange protocol.
Sorry for a response from a person not named Andy, but this is interesting.
I use Org mode for my notes, and I've been wanting some data structure for expressing more complicated relations between headline items. Basically, when a headline text is a node, I want a way to give its edges a variety of meanings expressing how they relate. Right now, we can only express hierarchical relationships by changing levels (i.e., the number of "stars"). Using the property drawer of the headline may be another approach, but it's not a natively-supported feature.
If we have this information, we can parse a tree to transform the outline text representation to something graphical rather easily.
Letting the leading symbol have the meaning, like you do here, may be one way. Or, perhaps Org headlines could be "enhanced" in such a way that they understand the relationship to their parent, e.g.,
or something along this line.
Anyway, thanks for an inspiration.