[ANN] Tachikoma.jl — A terminal UI framework for Julia

Tachikoma v1.1 — Terminals, REPLs, and Data Tables

What’s a TUI framework without the ability embed a terminal inside your terminal? Now you can go full Inception on your command line.

showcase

What’s New?

Terminal & REPL Widgets

Embed a fully functional PTY-backed terminal or an in-process Julia REPL directly into your app as a widget. Shell commands, Julia expressions, tab completion, syntax highlighting, etc.

PagedDataTable

PagedDataTable | Tachikoma.jl

A new data table widget for large datasets with server-side pagination, sorting, per-column filtering (contains, regex, numeric comparisons), global search, and keyboard-driven navigation. Comes with an InMemoryPagedProvider out of the box, plus a SQLitePagedProvider via the SQLite extension.

Other Improvements

  • Event-driven app loop, replaces polling in several spots with a wake channel; lower CPU usage, more responsive input handling
  • Adaptive sixel color quantization, dynamically adjusts palette size for better image quality
  • Dead space compression and per-frame GIF delays, resulting in smaller recorded GIFs with accurate timing
  • Many other bug fixes

Installation

pkg> add Tachikoma

Or to update:

pkg> update Tachikoma

This is such a cool project. This feels like a real natural fit for Julia, and a highlight for the language :slight_smile:

I mentioned this in [ANN] Sessions.jl, A terminal-native Julia notebook built on Pluto.jl's reactive engine and Tachikoma.jl - #18 by goerz, but it likely is a problem with the underlying Tachikoma (which I haven’t tried in isolation): The (presumably forced) dark background in all of the screenshots here is an absolute no-go for me. Please respect a user’s settings regarding their fundamental color scheme, and whether they are using light-on-dark or dark-on-light

Hey there, that reflects my own biases. But I’d like it to fit your preferences as well. There is a GitHub issue which I’d appreciate someone on the light side :wink: to contribute to. Should be a fairly easy task so if you’re interested please look at Provide theme for light mode · Issue #15 · kahliburke/Tachikoma.jl · GitHub

Just for the record, I’m totally fine if you were to submit a PR that was 100% generated using LLM based coding assistants. I will have my agent review what your agent generated, and it’ll get done very quickly!

It would be super cool if you had your agent write a bunch of unit tests too, I think there are over 4k such tests in the framework now.

That’s the sort of attitude that, among other things, strongly motivates me to avoid
having anything to do with LLM-coded software.

Hey, no offense taken. I encourage everyone to have the freedom to choose the code that they incorporate into their projects, the way they live their lives. It’s about agency, really …

(wait, did I just hear someone say agent-sy??? guess it’s time to go work some more on my multi-agent coding and research tool that’s in the works — Seaworthy.jl … ? :eyes: )

(PS the em-dash was intentionally written by a human)

It’s also very borderline with respect to the requirements for registered packages! There’s a very fine line here between AI-assisted coding and code deployed by LLMs without human intervention, aka vibe-coding, which is NOT acceptable for registered packages.

While it’s great that you’re creating this framework, I would urge you to curb your AI enthusiasm just a little bit, and remember that the fundamental design, the quality, and reliability of your package are still your responsibility, and not something you can delegate to an LLM. Moving fast and breaking things is not something that leads to a healthy ecosystem

I’m sorry, maybe I’m misunderstanding your point here, but are you saying that what I’m doing is very borderline? Have you tried Tachikoma.jl? :laughing: Do you think that it’s “acceptable”?

As for me, I think it’s pretty cool, pretty good, and just pretty.

If you’re able to achieve Tachikoma.jl level quality without putting in some serious work (aka human intervention) please tell me what model you’re using because I want it. :thinking:

Only via checking out Sessions, and having a glance at the README. At this point, I do think it looks very interesting, and it also does seem “acceptable” by the standards of the General registry. This is largely a function of the automated tests being in place and a proper and complete documentation, without any obvious sign of slop.

I don’t know… maybe little bit… As I said, it’s a thin line, and for right now I think you’re staying on the right side of that line. You do seem a little bit more enthusiastic about the promise of agentic coding than I would necessarily consider “wise”. The one thing that I think crosses the line is the idea that it’s okay for someone to submit a vibe-coded PR that then is reviewed and merged by and LLM without a human being in the loop at all. I’m going to assume that comment was a bit tongue-in-cheek, and not something you do on a regular basis.

Right, exactly, the “serious work” is a key part here. I do think you’re putting in that serious work, so you’re fine. But it’s easy to let things get away from you with agentic coding… These agents can very quickly produce more amounts of code than an human can reasonably still process. Once you end up with a system that is too byzantine (unnecessarily) for any human to still have a good understanding of the design and structure of the package, you’re in real trouble. I don’t think that’s necessarily where you’re heading with this package. But still, my instinct is to tell you to slow down a little :wink: Or, if not “you” then others who might be getting a little carried away with agents generating code for them, when they don’t have the experience to gauge the result in a meaningful way.

No, I meant that sincerely. I would definitely do that.

@kahliburke you are doing an excellent work!

I’m not trying to take over the conversation, but “vibe code” is something that’s going to be a part of our new reality, and we should all get on board. Open source exists because people give their time and energy to create software out of their free time. So, I truly believe that people in the open source community should have the freedom to do whatever they want. OpenSUSE has a great way of putting it: “The makers’ choice.”

If I had access to agentic workflows back then, PrettyTables.jl and SatelliteToolbox.jl might have been way better than they are now. I spent ages trying to create a TUI framework for Julia in TextUserInterfaces.jl using NCurses, and I’m still just getting started. @kahliburke has created something much more powerful and advanced without using any external libraries. The result is clear: Tachikoma.jl works perfectly. I’m migrating a TUI for our satellite simulator, and it’s much faster than the ncurses version.

So, my humble suggestion to @kahliburke is: continue doing whatever you are doing and wanting because the outcome is impressive!

Hello to all you robot lovers out there! Good news for you tonight, the Julia registry minions are hard at work packaging up the brand new

🌗 Tachikoma.jl v1.1.3

-- your terminal no longer has to live in the dark. 🌑 → ☀️

This release adds light mode with 13 new light themes (24 total), ANSI escape sequence rendering in Paragraph and ScrollPane, and per-row/per-cell styling for DataTable.

Hit Ctrl+\ then Tab to browse the light theme pack — Paper, Latte, Sakura, Gruvbox, Frost, and more. Pixel canvases (sixel/Kitty) automatically match the active mode.

Also fixes a Windows crash from a POSIX dup() call and a regression where sixel/Kitty canvases ignored light-mode backgrounds.

Full release notes: Release v1.1.3 · kahliburke/Tachikoma.jl · GitHub

Quick update, pushing out a minor patch release right now:

v1.1.4 - errors in @spawn’d apps no longer disappear into the void. Thanks to @Ronis_BR for identifying and reporting this. :satellite_antenna:

I haven’t tried this package, but this bit caught my eye:

Have you considered picking light/dark based on OSC foreground/background queries, and using the user’s 3-bit colours (and derived colours if more are needed) as a default theme?

Yes, I’ve considered it, but have decided not to invest time In it right now. PRs are welcome if you’d like to provide an implementation. There are many terminals and one of the more time consuming aspects is testing on the assortment of them. Contributions are appreciated.

You might find WIP: Read the terminal colour scheme on REPL startup by tecosaur · Pull Request #59958 · JuliaLang/julia · GitHub of some interest.