Would love to hear more about this approach.

It's actually really easy in Claude Code. Get a TUI to the point where it renders something, and get Claude to the point where it knows what you want to render (draw it in ASCII like this post proposes, for instance).

Then just prompt Claude to "use tmux to interact with and test the TUI rendering", prompt it through anything it gets hung up on (for instance, you might remind Claude that it can create a tmux pane with fixed size, or that tmux has a capture-pane feature to dump the contents of a view). Claude already knows a bunch about tmux.

Once it gets anything useful done, ask it to "write a subagent definition for a TUI tester that uses tmux to exercise a TUI and test its rendering, layout, and interaction behavior".

Save that subagent definition, and now Claude can do closed-loop visual and interactive testing of its own TUI development.

Can you explain tmux's contribution here? I'm confused why this process wouldn't work just the same if CC directly executed the program rather than involving tmux. Are you just using tmux to trick the program under test into running its TUI instead of operating in a dumb-stdout mode?

It allows Claude to take screenshots and generate keyboard inputs. It's like TUI Playwright.

Maybe I'm not understanding it (totally possible!) but could Claude just do that by reading standard out and writing to standard in?

I had a really hard time getting anything like that to work (you can't just read stdout and write stdin, because you're driving a terminal in raw mode), but it took like 3 sentences worth of Claude prompt to get Claude to use tmux to do this reliably.

I tell Claude code to use an existing tmux session to interact with eg a rails console, and it uses tmux send-keys and capture-pane for IO. It gets tripped up if a pager is invoked, but otherwise it works pretty well. Didn’t occur to me to tell it to take screenshots.

`tmux capture-pane`.

I would love to see your prompt if you ever post it anywhere.

For Claude, it's enough to prompt "use tmux to test", that usually does the work out of the box. If colors are important I also add "use -e option with capture-pane to see colors". It just works. I used it regularly with Claude and my TUI. For other agents other than Claude I need to use a more specific set of instructions ("use send-keys, capture-pane and mouse control via tmux" etc.)

Since I have e2e tests, I only use the agent for: guiding it on how to write the e2e test ("use tmux to try the new UI and then write a test") or to evaluate its overall usability (fake user testing, before actual user testing): "use tmux to evaluate the feature X and compile a list of usability issues"

Thank you!

Also many CLIs act differently when invoked connected to a terminal (TUI/interactive) vs not. So you’d run into issues there where Claude could only test the non-interactive things.

So by screenshots you mean tmux capture-pane, not actual screenshots. So in essence it is using stdout, just not Claude’s own.

"In essence" but terminals do stuff to render stdout that you do not want a LLM to have to replicate, I think. If your TUI does stuff in fullscreen or otherwise with a bunch of control codes, that is simple work for a terminal but potentially intractable for a LLM.

While I like the concept, the side-effect pattern might be difficult for the average developer to understand (without fp-pack knowledge) in a shared codebase:

https://github.com/superlucky84/fp-pack?tab=readme-ov-file#s...

Still, this approach is very useful for most business logic, too bad most programming languages don't provide a nice syntax for this.

That’s a fair point, and I agree.

The SideEffect pattern is intentionally explicit, so without fp-pack context it can look unfamiliar at first. The trade-off is making early exits visible in the code, rather than hiding them in conditionals or exceptions.

In practice, most code stays in plain pipe/pipeAsync. SideEffect is meant for a small number of boundary cases only.

And I agree — better language-level syntax for this kind of pattern would make it much easier to adopt.

What are popular charm/bubbletea based TUIs? I use TUIs often, but for some reason none of them are based on charm/bubbletea? Might be coincidence though.

While I appreciate Charm's aesthetics, I worry it leans too heavily on GUI paradigms, like popovers and buttons, rather than prioritizing the optimal keyboard efficiency used in traditional text-based interfaces.

I like the terminal-based LLM tool, Crush. I find it handy in that I can pull it into any IDE and it works the same.

- https://github.com/charmbracelet/crush

Maybe this could be helpful? -> https://github.com/pimalaya/neverest

Wait until they get to the networking layer; you're going to hate what Vint Cerf did in the 70s :)

> But I am using Oberon-07 as base, and I might deviate from it quite soon too.

I am curious about your thoughts on var parameters (i.e. mutable references), as in:

    proc increment(var x: int)
    begin
      x := x + 1
    end

    var i: int

    begin
      i := 10
      increment(i)  // i is now 11
    end

i also wonder about this concept; is there a programming language that has this behavior?

Ada, Nim, Pascal. I think C++ also offers it with a specific syntax.

Rust also offers it, but you need to specify it on the call side as well.

Fortran can do "in out" arguments to subroutines also.

Isn't this wat streaming databases like Materialize and RisingWave do?

How does it differ from https://weasyprint.org ?

WeasyPrint is great, but PlutoPrint takes a different angle: the engine is all C++, so it’s faster and lighter on memory. It can render directly to PNG as well as PDF, and has stronger SVG support.

PlutoBook looks very impressive. Is it based on another renderer?

Doesn't look like it:

> PlutoBook depends on the following external libraries:

> Required: cairo, freetype, harfbuzz, fontconfig, expat, icu

> Optional: curl, turbojpeg, webp (enable additional features)

I don't care much for the eye candy either, but I do appreciate how gradient borders look:

https://cdn.imgchest.com/files/y2pckdepoa7.png

That's the only eye candy I would wish for in Sway or SwayFx.

There’s a 500 line script called “xborders” that will draw eye-candy borders on i3. By default I think it does solid colors, but it is 500 lines of Python, I bet you could customize it to draw whatever gradients you want. Needs a compositor, of course.