Future Office Labs

DAGEdit, Now in Clojure

Fri, 06 Nov 2026 00:00:00 +0000

A quick update on the keyboard DAG editor.

The first version was a JavaScript experiment in the browser. I've now rewritten it in Clojure. The main version is a TUI: it runs in the terminal, edits a graph saved as a .json file, and opens a node's details in your $EDITOR.

The editor itself is written once, as shared Clojure / ClojureScript code that draws the screen as a grid of characters. The terminal version prints that grid. And the same code, compiled to JavaScript, is the new web version, which looks just like the terminal.

The web version has one thing the terminal doesn't: a Graphviz drawing of the DAG. Ctrl+P pops it up, and P pins it, so the editor is on the left and the graph is on the right, redrawn as you type. From there you can download the graph as SVG, PNG, DOT or Cypher.

Your graph is saved in the browser as you go. Ctrl+S downloads it as a .json file, and Alt+O opens a .json or a Graphviz .dot file.

Some of the keys have changed since the first post:

Key	What it does
Ctrl+F	fork: a new connected node in the next column
Ctrl+Y, then Ctrl+V	copy a node's output, and paste it as an input on another node (a merge)
Ctrl+K	delete a node, joining up the nodes either side
Ctrl+E	the connections palette

F1 lists them all.

Try it here: DAGEdit.

The Worst Idea in Computer Science

Fri, 06 Nov 2026 00:00:00 +0000

I sometimes call "direct manipulation" the "worst idea in computer science". It's a brilliant idea. And precisely because it's so good, it's become so pernicious.

But hopefully, its reign of despottery is ending.

The kernel of truth inside the hype of the "AI revolution" is that we are moving to natural language as the main user interface paradigm for computers. There is now very little need for the GUI. For pointing at things with mice. For scrolling. For direct manipulation.

The main advantage that GUIs claimed over text terminals was "discovery". I didn't know what my software could do until I looked at its menu options. But now discovery is as easy as asking it "is there a way to do X?"

You can see the attraction of the natural language paradigm in both the popular enthusiasm around agents like OpenClaw. And in the enthusiasm for the TUI and tiling window managers among the geeks. People who are keen users of computers are overwhelmingly voting for natural language UX. And the future of software is "agentic" this way. Natural language UI. And at least enough knowledge and memory in it that a user can meaningfully delegate long term and batch processing work via natural language.

As an aside, it's fascinating to observe that we've been so immersed and constrained by the "direct manipulation" paradigm for end users, that batch processing, processing on a timer or cronjob, and event driven processing all seem miraculous to most users. These possibilities have been in our operating systems since the 1970s. But the direct manipulation paradigm obscured the possibility from all but the most technical. If LLMs do nothing but bring the masses the virtues of "indirect manipulation" they'll have been worth it. Over the past 40 years, the direct manipulation paradigm enshitified from helpful (here's what you can do) to manipulative (here's another thing to grab your attention, keep scrolling)

Chatbots, at least for the moment, are a reset to a self-service, user pulls what they want, model. Rather than the UI pushing more distraction at you. (Though beware! I'm sure there are people working on reversing that.) The next OS will be made of chatbots in the way current UIs are made of windows. Your software needs to fit into that paradigm.

This is something I wrote on LinkedIn in response to this

A DSL for UI Layouts

Sat, 29 Nov 2025 00:00:00 +0000

I know this is probably more me than you, dear reader. But I just don't like working in two dimensions.

Laying out things like web-page designs or UI designs is a faff. If I use the mouse it's just OK. But a bit laborious.

On the other hand, declarative HTML-like and templating languages SHOULD be fine. But can become hugely complicated.

That's because

a) in something like html, the layout is verbose anyway.
b) with CSS, some layout can end up in separate CSS files, which means you are looking all over the place to see what's going on
c) layout information is often muddled up with the content that's being laid out.

Now the separation of concerns which the HTML / CSS distinction is meant to represent is a fine thing. But in practice the two don't come apart so easily.

And in other ways of building forms, imperatively, in more traditional GUI libraries, we don't even have the virtues claimed for HTML. And again, the layout and the rest of what happens in the layout can get very intertwingled.

So I've been thinking for a while about a nice simple DSL that should represent just layout information. Just how a space should be carved into regions.

I played with an early prototype of this as an example in Neh-Thalggu

This week I've been exploring Canva apps from a developer perspective. I've been playing with putting some Patterning-derived apps there. But while doing so, I wondered whether my DSL would also work for making forms there.

And so I'm also playing with expanding this UI DSL a bit. To define, at first, paper forms.

The core idea is that all layouts are effectively blocks that are nested and arranged either horizontally or vertically. So why not use two different kinds of brackets, one for each?

In my DSL we use square brackets to represent vertical flow. So

[header body footer]

means header, body and footer flowed vertically.

Angle brackets represent horizontal flow. So

[header <col1 col2> footer]

turns the second section into two columns. And we can go on, nesting as much as we like.

[header 
   <maincolumn
     [sidebar1 sidebar2 sidebar3]>
 footer]

Now it's important to note here that the language doesn't assign any meaning to the labels we give. These are really just symbols that mean whatever the user of the language wants them to mean. In the Canva app I'm working on, they just become text headers. While in a code-generator or Neh-Thalggu or embedded in a GUI framework, they might be references or tags that can be matched to specific GUI components.

Even with this simple language we can already say (and read) things clearly and concisely, that would otherwise be lost in the thickets of other functionality.

But we do need more control over relative sizes of the boxes. By default they are evenly divided. So if there are three things in a vertical flow, we assign a third of the space to each.

We can change this by adding a suffix to a label. This suffix represents (roughly) the ratio of the space this element should take up compared to its default. Let's suppose we think the header and the footer don't need to take up their full third of the screen. But only a proportion of that allotted space. We'd write something like this

[header(1/2) 
   <maincolumn
     [sidebar1 sidebar2 sidebar3]>
 footer(1/2)]

This tells the layout engine to halve the space for both header and footer to the equivalent of 1/6 of the total vertical space each. Leaving 4/6 for the main section. In practice it doesn't work out exactly like this. Each specific request for space impacts the share that other sections get. But it's close enough that, with a small amount of fiddling, you can find reasonably nice proportions for each section.

If we want a section to claim more of the available space, we put a ratio that's greater than 1. In this example, the maincolumn demands 3 times its half of the width adding up to 3/4.

[header(1/2) 
 <maincolumn(3)
      [sidebar1 sidebar2 sidebar3]> 
 footer(1/3)]

Here's how the above gets rendered.

So. I think this is plausible. If I need to make simple SVG page templates, with labelled boxes I can. And I ~~think~~ hope this might well be a useful little tool in Canva. (Though with the caveat I'm not sure the average Canva user will particularly like working this way.)

The bigger test will come when I get back to the suite of music composition apps I'm currently working on, where I need to define a more complex GUI. I'm hoping I can use this to generate the layout code for that. But we'll see.

In the meantime, you can play with it here

And at some point the revised, improved version of this language will find its way back to Neh Thalggu as an example DSL there.

Voice Labelled Graph Editor

Tue, 25 Nov 2025 00:00:00 +0000

I am, as I may have mentioned, a bit obsessed with graph editors.

DAGs and other graphs are hugely important. And we want to tell the computers about them all the time.

However they don't map conveniently on to text.

And this infuriates me because I like text. A lot. I think text is the greatest UI known to humanity. That's why we evolved to speak not sign to each other. And alphabets not ideograms took over the world.

So it pains me, deep in my soul, that when making graph-shaped things that I love - from synthesisers to dataflow pipelines and process models - that text (and lexical scoping) doesn't quite work for them.

Perhaps we just DO need to draw graphs with something else. I need to be flexible on this.

But what's really annoying is continuously having to switch between mouse and keyboard when editing a graph. Mouse for the topology, and keyboard for the labelling of nodes.

So my last project in this area was the Keyboard Only DAG editor. And that works pretty well. (As an idea. There are a couple of bugs in the implementation)

But what about turning the problem around? Instead of staying on the keyboard, being able to stay only with the mouse or drawing tool? The issue here is how to label the nodes. To tell the computer what each is meant to be and what extra data it holds or function it executes.

Well, if my hands are occupied with the mouse, what about my voice? Are we yet in a stage where we can use voice to label nodes?

I made a simple experiment using the Vosk voice recognition model, that runs completely in the browser.

The fact that it's do-able in the browser is one of those things that still impresses me but I need to recalibrate my expectations to get used to. But it's still not great.

Nevertheless, I can imagine this combination of drawing + voice might well become a comfortable way of working for many people on many tasks. To me neither drawing nor voice have the virtues of typing text. But combined they become far more compelling.

When I have the next, better, demo of something like this, I'll put it up to play with.

The Douat for Patterning

Thu, 16 Oct 2025 00:00:00 +0000

I'm still resonating from the awesome Alpaca Festival I attended a few weeks ago. There were many stimulating ideas there. Not least another presentation by Rocco Lorenzo Modugno and his colleagues. Building on an earlier tak on the tiling pattern notation of Dominique Douat which uses the letters A,B,C and D to represent 4 orientations of a square tile, divided diagonally into black and white triangles. You can build many complex patterns out of such triangles simply by playing with their orientation.

Anyway, inspired by this, I decided to implement something similar in my Patterning library. A simple notation, or "Domain Specific Language" for the orientation of tiles.

But as Patterning is all about composition of smaller patterns into larger ones, I made A,B,C and D represent not simply rotated tiles, but functions to rotate any pattern in one of the four orientations. I then invented a structure I called the Douat.

A Douat is slightly strange and convoluted to explain. But very easy to work with.

Essentially a Douat object starts with a pattern inside it. And we pass it through a series of these "Douatic" transformation functions. Initially it starts taking those transformations and storing copies of its pattern transformed by them. Then when it has collected 4 of these transformed patterns it turns itself into a larger pattern with one of each of these transformed versions of the pattern in each quadrant. If we continue to pass it through the Douatic functions we will be able to play the same game with this first compound.

Let's step through.

If we pass the Douat through the following

    A A A A

we will get the same tile repeated in each quadrant.

On the other hand, if we pass it through

    A B C D

we get different orientations in each quadrant

If we move to a second row,

A B C D
A A A A

We get that initial compound of four tiles now repeated itself 4 times.

In practice that original compounded pattern made with A B C D has a rotational symmetry so it doesn't matter what orientation we make it. But suppose we make the first level less rotationally symmetric, as in

A B D C

Then

A B D C
A A A A

will look like

But

A B D C
A B C D

will look like

And we can keep going as long as we like.

Reflections

We can supplement the rotations with reflections : horizontal, vertical and both. These are defined as the functions E, G and F respectively. This gives us a wider vocabulary of transformations to play with.

We can start with a simple A E G F combination. As in

and build it into complex patterns like

with

   A E G F
   A B C D
   A B F B
   C F C D

The first pattern on this page is made with :

    A E E A
    A B C D
    A E G F
    A A A A

Because this is Patterning, we aren't restricted to just the Truchet triangle tiles. Any pattern can work. So we can start with any simple tile and build it into something beautiful.

How The Douat Works

Here's the fairly short code implementation of the Douat itself.


(defn Douat [p] 
  {:p p
   :ps []
   :depth 0}
  )


(defn add-douat [f]
  (fn [{:keys [p ps depth]}]
    (if (< (count ps) 3)
      {:p p
       :ps (concat ps [(f p)])
       :depth depth
       }
      (let [q
            (stack
             (->> (nth ps 0) (scale 0.5) (translate -0.5 -0.5))
             (->> (nth ps 1) (scale 0.5) (translate 0.5 -0.5))
             (->> (nth ps 2) (scale 0.5) (translate 0.5 0.5))
             (->> (f p) (scale 0.5) (translate -0.5 0.5))
             )]
        {:ps []
         :p q
         :depth (+ 1 depth)
         }))))

(def A (add-douat identity))
(def B (add-douat (fn [p] (rotate (/ PI 2) p))))
(def C (add-douat (fn [p] (rotate PI p))))
(def D (add-douat (fn [p] (rotate (* 3 (/ PI 2)) p))))
(def E (add-douat (fn [p] (h-reflect p))))
(def F (add-douat (fn [p] (v-reflect p))))
(def G (add-douat (fn [p] (-> p (h-reflect) (v-reflect)))))
(defn R [douat]
  ((rand-nth [A B C D]) douat))
(defn Q [douat]
  ((rand-nth [A B C D E F G]) douat))

The implementation consists of defining a Douat itself. It's a simple map or dictionary with three fields : :p is the current pattern, :ps is the list of the next collection of patterns we are building up. And :depth is a depth tracker. The Douat function creates that map from an initial pattern.

The functionality of the Douat is encapsulated in the function add-douat which is not intended to be used directly but which is a higher-order function that adapts any function that transforms a normal pattern, into a function which works on a Douat-wrapped version of the pattern.

This allows us to use it in the Douat world. Is it like a "monad"? It not really a monad, but it's kinda that way of thinking. We want to make a bunch of functions composable into a pipeline where they all receive and return Douats.

So when we call a Douatic function on a Douat it does one of two things.

If we haven't yet collected four new pieces of pattern, it just applies the wrapped transformation to the Douat's current pattern, and appends it to the list that's building up at the :ps key. And returns the Douat

If it is passing through the fourth Douatic function in the sequence, it now creates a new pattern with one of the transformations of the old pattern in each quadrant and makes this the new pattern at :p. And then it wipes the :ps list to start collecting four more transformations.

So as the Douat passes through a pipeline of Douatic functions it collects them into groups of four, using each to make one quadrant of a new pattern. And this is indefinitely recursive, to build up increasingly complex patterns of more and more tiles.

The functions we currently create are the orginal A, B, C and D inspired by Douat's notation. We then extend this with E, F and G which are reflections (as opposed to rotations). And R and Q which randomly choose one of the others.

Why do we use such short cryptic names? Because this lets us write code like this :


(def my-tile
  (stack
    (square {:fill (p-color 90 0 0)})
    [(->SShape
       {:fill (p-color 0) 
        :stroke-weight 1
        :stroke (p-color 255 255 0)}
       [[1 1] [-1 1] [-1 -1] [1 0]])]))

(-> my-tile

   Douat

   A E E A
   A B C D
   A E E A
   B E E B

  (:p)
  )

Here we create the initial tile with standard Patterning functions.

Then we use the threading macro to make the simple pipeline that will send the pattern first through the Douat function to wrap it as a Douat. Then through a series of Douatic functions. Because these are single letter names we can just group them in lines of 4 to make them intelligible.

Finally we want to extract the end pattern from the Douat wrapper, this is what the (:p) does.

In practice we could wrap any of Patterning's functions that transform patterns to work in this Douatic way.

You can play with the Douat within the Patterning Workbench on my Alchemy Islands site.

The nice thing about the Douat is not just that it gives us a very powerful and concise way to make a lot of quite beautiful patterns. But that the implementation turns out to be so simple and elegant. Inventing it has taught and inspired me a lot about the power of functional thinking. You can imagine building up many other expressive DSLs this way in Clojure. The fluent "MailQuery" library I wrote in Python recently has some similarities. But this one I really find cool.

Keyboard DAG Editing

Wed, 15 Oct 2025 00:00:00 +0000

Directed Acyclic Graphs or DAGs are an important data-structure for representing any kind of processing pipeline.

They turn up in audio applications, from modular synthesisers to Pure Data patches. (As long as there are no feedback loops.) They are used in Machine Learning pipelines. In continuous integration and delivery of software and other business processes.

Something that I've long thought about are different ideas for editing DAGs. Typically we use custom editors highly coupled to a specific application. Mostly these are variants of drawing boxes and arrows. Or "node based" editors.

But I'm always fascinated by the idea of generic editors for particular data-structures. When we decouple the editor and the structure from the particular application, we unlock a lot of potential value as we can then quickly think of applying the structure in new contexts.

We have these for text. (Most code editors handle multiple programming languages. Even word-processors aren't specific to "novels" vs "business letters".) And image editing. And spreadsheets for grid or table-shaped data. But rarely for other data shapes.

I've played around with writing my own generic boxes and arrows type editors. But one thing that I don't particularly like is having to use the mouse. It's not that I dislike the mouse in itself. It's that anything that forces a lot of switching between mouse and keyboard gets frustrating. And in my experience, much data-flow DAG editing involves a LOT of backwards and forwards between the mouse and keyboard.

Wouldn't it be great if we could have a simple, purely keyboard way of editing DAGs?

Well DAGs often DO have text representations. Graphviz is the popular open-source library for visualising DAGs and is based on the DOT text format. Pure Data has its own text-based file format.

But such text files aren't intended for humans to read or follow. They don't show the graph structure clearly. And editing them often requires you to remember arbitrary IDs for nodes. These formats are also tightly coupled to the specific application.

I'd like something which feels like a simple text editor, that is completely keyboard controlled, and which nevertheless lets me clearly see, understand and edit the DAG structure.

So the other day, I had some thoughts and set down to vibe-code a concept demonstration.

The main "insight" is to borrow a multi-column paradigm from spreadsheets. Arrow keys are fine for navigating a 2D grid of cells. And while a DAG is NOT a grid, we can nevertheless overlay a DAG onto a grid relatively "efficiently". By which I mean, we only need as many columns as our maximum number of parallel paths through the graph. And we can often squash multiple paths into the same column as long as they are not overlapping.

We treat a column in the grid a simple sequence of nodes. Each automatically connected from the one above. We use a specific key shortcut, ctrl and "+" to fork a second sequence. This moves into a new empty column. We also have a way merge a sequence back into another sequence. This starts by "grabbing the output" from a node, with ctrl+Return. And then pasting it onto another node with ctrl+v where it is treated as a second input.

With these three extra key controls - fork, grab output and paste input; and navigation within the grid using Shift+arrow keys - we have the ability to build up our DAG with simple keyboard presses.

The final requirement is to delete nodes and connections. Ctrl-backspace deletes a node. While deleting individual connections requires a pop-up "palette" opened with ctrl+"." We can navigate within this palette with arrow keys and delete unwanted connections with the backspace key.

So this is just a first experiment. It's buggy and somewhat klunky but you can play with it and get a feel for using it here : DAGEdit. When the code is in better shape and some of the more egregious bugs are ironed out, I'll make it available.

MailQuery

Tue, 12 Aug 2025 00:00:00 +0000

I admit, I like jQuery. Not jQuery as a full web UI framework, but the notion of a simple, "fluent" interface for accessing something complicated like the DOM, that jQuery introduced me to.

Every now and then I need to do something with another complicated thing and a light-bulb goes off in my head and I think "I wish I had an xQuery for that."

I originally did it when I got bored with crawling around my file-system the old-fashioned way. And wrote https://github.com/interstar/FSQuery

Meanwhile, I've always hated Gmail filters. And increasingly I've been thinking about whether AI might finally help to get my aburdly cluttered Gmail inbox under control.

But then I realised I just wanted a better way to talk to my mailbox from Python. So I've been vibe-coding for a few days, and here's the result, a Python library called "mailquery" : https://github.com/interstar/mailquery

Here's how I can currently manage my Gmail account, in the REPL with a fluent interface and FP attitude.

Import from the library

    from mailquery import GmailClient, Mailbox, SQLiteStorage, OR, spit, HTMLPageBuilder, SenderCollector, EmailStatistics

Create the gmail client. The credentials are in "credentials.json". Note the library also has a plain IMAP client

    client = GmailClient("credentials.json",allow_delete=True)

Create mailbox from the client. Filter for emails later than 1st August, 2025 that are from either one of hello@restofworld.org or ai.plus@axios.

    news = Mailbox(client).after("2025-08-01").from_(OR("hello@restofworld.org","ai.plus@axios.com",))

Note this is a "fluent" interface where you chain filters together with the dot operator. Each filter call adds itself to the Mailbox and returns the Mailbox. There are standard built in ones like from_, to, before, after, subject_contains etc. You can add as many as you like.

OR is a special class that represents any of the arguments. from_(OR("hello@restofworld.org","ai.plus@axios.com")) matches emails from either of these two addresses. The OR can handle as many values as you give it.

There are also the two generic filters : include_when() and exclude_when() These take "predicate" functions. That is, functions which map from an email object to a True/False value

Make sure you understand this concept clearly. "include_when()" means if the predicate returns True, then this filter allows the email through to the next stage "exclude_when()" means that if the predicate returns True, the mail is blocked from passing through to the next stage. But will pass through if the predicate returns False

Anyway, after the last command, "news" now contains a mailbox with the after and from_ filters attached.

But note that nothing has actually run yet. MailQuery is a pretty lazy library.

Let's now just list the mails that match. verbose=False prints just the basic header, verbose=True would print a bunch of extra warnings and diagnostics.

    news.list_all(verbose=False)

This has now triggered the query to execute. It ran through the mailbox looking for emails that matched the filters.

Note that all the filtering is done on the client. Which means downloading all the email headers to test them against the criteria BUT as an optimisation for Gmail, both the after() filter and the from_() filter get turned into Gmail server-side filters by our GmailClient class. This makes things MUCH faster, but is completely transparent to the user. You don't need to know anything about Gmail to get this benefit. It's entirely handled by the GmailClient class we used when we created the Mailbox object.

If you aren't using Gmail, or a server where we can use such optmisations, then MailQuery will just chug along, slowly, downloading all the mail and filtering it locally. It's much slower, but it works identically

Remember I said MailQuery was lazy?

At this point the mail headers have been downloaded and cached. If we run list_all() again, we'll just pull them out of the local cache.

However the bodies of the emails are not yet downloaded. And won't be until something calls a get body or get html type function on them. body_contains(), a test whether a string is in the body of the email, is one such filter. If included in the filter chain it will force a download of the email body.

Once bodies are downloaded, the Email objects in the mailbox will cache that too.

Perhaps we want to store the emails that matched our criteria. A Storage object can do that. And we place a store_local() end point on our filter chain.

    storage = SQLiteStorage("newsletters.db")
    news.store_local(storage)

And that's it, the emails are stored in the database. We can now delete them from the gmail account

    news.delete()

But wait, there's more! These newsletters have all their useful stuff in an HTML attachment field. That's a pain. We can extract the text from the html with Beautiful Soup. But we don't really want to hardwire Beautiful Soup into our mail library do we?

We would like a way to optionally process a field in the mail record into some further information.

We also want to store this extra information in the email.

Fortunately, MailQuery has a mechanism for that : add_attribute(att_name,fn)

add_attribute() works like a filter. But it always returns True. It never removes anything from the mailbox.

What it DOES do is transform the email in some way. The function fn needs to be a function that maps emails to some other value. att_name is a string . The add_attribute filter calls fn on each mail passing through, and stores the result in an extra attribute under the name `att_name

For example, we can use Beautiful Soup to extract text from the html like this.

def extract_html_text(email):
    try:
        html_content = email.get_html()
        if html_content:
            soup = BeautifulSoup(html_content, 'html.parser')
            return soup.get_text(separator=' ', strip=True)
        return ""
    except Exception as e:
        print(f"Error extracting HTML text: {e}")
        return ""

Now we can add this as a new attribute

news.add_attribute("html_as_text",extract_html_text).store_local(storage)

Not only does the add_attribute add the extra attribute to all the emails. It also registers the extra attribute name in the Mailbox

Then when we call store_local(storage), storage finds out about the extra attribute name and creates an extra column for it in the SQLite database

But wait there's MORE ....

We can filter. We can "map" mails to other values? Why not have trifecta and add some kind of fold or reduce?

list_all(), delete() and store_local() are three functions we can add at the end of the pipeline to do something with our email

But we also have a generic way to roll them up to get some kind of aggregate value out of them.

Unsurprisingly it's called reduce_all(reducer)

Here's what a Reducer has to look like

class Reducer :
    def init_value(self) : # returns initial value
    def fold(self, next:ParsedEmail)  : # folds the next email into its internal accumulator 
    def final(self) : return the final value of the accumulator

Let's use one to count the emails in our mailbox

class Counter(Reducer):

    def init_value(self):
        self.count = 0

    def fold(self, email: ParsedEmail):
        self.count += 1

    def final(self) -> int:
        return self.count


mails.reduce_all(Counter())

Something more useful is to discover all the unique email addresses in a matching mail set

class SenderCollector(Reducer):
    """Collect all unique sender email addresses"""

    def init_value(self):
        self.senders: Set[str] = set()

    def fold(self, email: ParsedEmail):
        self.senders.add(email.envelope['from'])

    def final(self) -> List[str]:
        return list(self.senders)

mails.reduce_all(SenderCollector())

I hope you see how this thing starts to stack up

Apart from the delete() WHICH IS BLOODY DANGEROUS ... BE VERY CAREFUL WITH IT

Apart from the delete() nothing else changes your mailbox. And everything gets cached locally

So once you've run a mailbox filtering once, whether to print or store, runnning these further reducers will just iterate through mails in memory

MailQuery is powerful for any automated email application. But my goal is to be able to use it in Python REPL to interact with my Gmail dynamically but programatically.

One thing missing from all the automation above is a way to bring the human back into the loop. Sometimes even I can't think of a criterion for deleting or saving emails except by reading the mail and making a personal decision

Never fear, we can bring the human back simply by invoking human()

mails.subject_contains("important").human().delete()

human() works like any other filter on the email chain. Except it turns the terminal into an interactive window where a human user can review and decide the fate of an email. The human can type "D" or SPACE. "D" is obviously intended to signal "delete this email". In fact, because human() is just another filter stage, what it ACTUALLY does is return a True, indicating that the email is to pass through to the next stage of the filter chain. SPACE on the other hand returns False, removing the email from the filter chain. These obviously only work as intended if the human() is slotted into a chain which ends at a delete(). You could obviously use the human() elsewhere, but you are likely to confuse yourself or your users. Again, MailQuery is a dangerous power-tool which will hurt you if you are not incredibly careful.