Terminal borders that don't cost a cell

A good answer to this might be to ask yourself how would labeling them GUIs make something clearer?

I develop a log file viewer TUI and have resisted turning it into a GUI when people ask. Part of the reasoning is that it needs to work over SSH. The other part is that I find GUI log viewers are filled with junk that takes away from seeing the actual log messages. I like to complain about datadog/grafana/etc because there is so much ornamentation and other stuff that you end up with a fraction of the screen real estate for the meaningful text. Ultimately, the TUI forces you to focus on what matters.

I also like to complain about TUIs that put borders around everything since it wastes precious space. So, this is nice to see.

You got me at useless. Now I want to recreate something like this using tmux and a terminal window manager.

I really don’t understand why people keep on doing frames with gaps between them.

They make for superficial but attractive demos that challenge only uncontroversial or inconsequential preconceptions without demanding much else from the viewer.

In other words, you can put together something that looks kind of pretty (if you're just scrolling and don't occupy yourself with how you would use the programme being demonstrated); that looks very similar to something you're very familiar with (often, the demos involve recreating well-known GUI applications); that challenge the preconception that terminals and window managers are very separate and distinct things; that challenge the preconception that terminals are very obscure and difficult-to-use-things; that reässure the viewer that the purported complexity of creating, maintaining, packaging, or distributing a GUI may somehow be avoidable (after all, creating a “CLI” is so easy, it's where most introductory educational materials for programming start!); but also do not challenge the viewer to consider that to create an interface of high utility, there is an unavoidable and often very significant level of effort required (irrespective of the interface medium); and do not challenge the viewer to consider the serious gaps in their own knowledge (e.g., that, despite their years of experience using CLIs, many don't even understand how to design a good CLI of any moderate complexity†!)

† Seriously, most corporate CLIs are so preposterously bad, I wonder what they're even teaching people in school. It's a marvel when you run across one where the author considered, even fleetingly, “maybe we could read (line-delimited) input data from stdin…?” Frameworks made this worse. With LLMs, there is no hope left. (Median LLM CLI design is atrocious.)

In the era where creating demos required significant effort, we'd often marvel at what someone could create, and our attention would move on before the discussion would ever move to considering “is this thing actually useful?”

A friend of mine recently used an LLM to quite faithfully recreate the Bloomberg interface for financial data analysis. They didn't write a single line of code. It took about a weekend of work. Five years ago, this would have gotten them an unending stream of job offers. Today, instead, they got a bunch of social media posts… and a few days later, no one cares. Does the thing look very slick? Yes. Does it actually work? I guess? I don't know if anyone on social media even installed it. Does it do anything better than a Bloomberg terminal? Who knows? Is it competition for Bloomberg users? Probably not. Is there anything we can learn from their code, their design, their effort? No.

Setting this aside, your underlying supposition—one which I share—is that the various interface media (in this case, terminal-based vs window-manager-based) are sufficiently distinct that their design demands specific effort. An interface design that works in one medium will not “fit” in the other. Designing for a GUI should be very different than designing for a CLI or TUI.

If we investigate more closely, it's pretty clear that there are extremes where this assertion is obvious true and where this assertion is not obviously true. That is, on one extreme, we have programmes like, say, (the simplest version of) top which probably wouldn't look very different as a GUI. At the other extreme, we have CLIs, and I don't think I even need to name an example to help conjure a vision of a workflow that is impossible to reproduce as a GUI. Somewhere in the middle are TUIs, which I think are on unsteady footing, though I think terminal protocol extensions (such as those proposed in this post) are actually mostly harmless.

As you note, TUIs seem to demand a different design approach than GUIs, as a result of their cell-orientation and other related fundamental limitations. For example, because cell size is uniform, all graphical elements are uniform, and because “zoom” operates at the terminal level, we don't have dynamic resizing; therefore, your terminal window is generally sized and zoomed to the cell-size of the least important text in the interface; therefore, your terminals $LINES and $COLUMNS are always too few; therefore, we're often cramped, wanting for more space, and sensitive to extraneous whitespace like border padding.

I agree completely that a direct consequence is that visual style must subsequently adapt to these limitations to produce useful tools that are not simply demo-ware. From this perspective, the terminal protocol extensions proposed by this post would actually be very useful; however, it's probably fairer for the author to include as comparison a fallback mode of their demo programme that eliminates the visual styling. (This is basically what I would do, if I were writing such a programme: use all-edge borders more freely in the presence of the protocol extension and fallback to separating-edge borders or no borders in its absence, not just because it will likely look nicer and be less wasteful of space, but also because it will minimally inhibit naïf cut & paste.)

Similarly, as you note, it's true that TUIs are almost always a clumsy and discordant cramming of GUI metaphors into a foreign medium. However, I don't think that TUIs have to be this way. In fact, I suspect that there may be as-yet-undiscovered metaphors for TUI operation that provide a materially better interface to users than a CLI or GUI. That is, rather than considering the TUI as somewhere between a GUI and CLI, I suspect that the TUI may be it's own unique, distinct paradigm that has its own unique, distinct way of being operated. I don't know if there are many applications whose most effective interface is manifested in this medium, but I am fairly certain there are at least some.

Personally, I have recently been exploring the idea of programmatic, “non ad hoc” terminal multiplexing as an avenue for exploring this space further, and I think there's utility in this, but it's not clear whether there is really that much novelty, and I actually kind of doubt the idea will prove to be that revolutionary (but, still, probably very useful!)

Definitely not a necessary part of the spec - more something that I prefer on this and to demonstrate it in comparison to the existing solutions - the space makes it more clear there. But the thing about text is that words inherently need spaces between them to be readable. And TUIs exist generally in this weird text heavy, multi server / OS, keyboard focused, type heavy where GUIs aren't quite appropriate and people try to work around various shortcomings in the best way possible. Often the idea 'use a gui' is just not a relevant answer to the problem in the same way as why not use the vim gui isn't an answer for you.

There's a bunch of example TUI apps on https://ratatui.rs/showcase/apps/ that show various versions of what people tend to do in the terminal. These tend not to be the ones that I was saying were the problematic ones. But I'm sure they'll annoy your border sensibilities.

Unsure if you've posted something similar on hn a while back or if that was someone else, but I agree with you generally. I push back a bunch on bland boxes and borders apps a bunch in feedback

I just added a small collapsed version to the sample Ratatui app. Screenshots are in https://github.com/joshka/ratatui/blob/joshka/cell-borders/CELL-BORDERS.md#screenshots

Press c (or start it with TILING_PANES_COLLAPSED=1) and the panes sit edge to edge: no outer border, one shared line between neighbours, ┼ where they meet. With box drawing, every shared line still costs a row or a column. With cell borders, the line sits on the cell edge and the text keeps the whole pane.

The thing you'll notice is that the color of the border has to be owned by one of the cells on either side of it, so the approach here where borders are between cells neatly solves that problem

counterpoint: the most popular cell-oriented user interface out there is the spreadsheet, and cell borders have been a valued part of the design forever.

It's just where the energy is right now. iTerm2 and kitty have previously been places where that has happened a bunch in the past, xterm before it. Ghostty is different because of the rather unique nature of Mitchell doing a passion project combined with the LLM hockey puck nature of software development capacity and a need of people to massively parallelize command line stuff generally due to the same need for tooling. We're in a bit of an AI gold-rush era if you look at it that way.

I don't think that's a bad thing unless Ghostty were closed source, but it's MIT. You can rewrite it in rust if you want it (I've done this). Implement your own stuff on it if you want to (this too obv).

I also implemented this originally with Rio - same level of difficulty generally, and Raph has been pretty supportive of doing something with it.

I posted it on the Ghostty discussion because it feels right to get it in a real world terminal that many devs are gravitating to. Happy to post this other places too for it to be seriously considered as a proper option. But if you look at the recent OSC7501 stuff and how fast it went from Ghostty spec to implemented in a bunch of other places it's worth considering treating it as a place to start conversations around this sort of thing

Ghostty is starting to remind me of Chromium; a place where new standards for a platform are unilaterally inserted and by which others are pressured to adopt due to popularity.

I feel similarly ambivalent.

Ghostty is a fine terminal emulator (but I haven't tried all of the new ones, though I do also like WezTerm… and I should really try kitty again, since I had a really nice time meeting its core developer at PyCon India, who is really a lovely person.)

libghostty is extremely useful. As part of some background research, I was looking into the most minimal terminal multiplexer and collecting short examples (similar to the list of X11 window managers with <10k lines of code.) I intended to use these as a starting point for developing my own ideas; however, I abandoned this approach after creating a simple demo in Zig using libghostty. In fewer than a couple hundred lines of Zig code, I was able to create some very complex proofs-of-concept on top of the libghostty state machine (which is both easy to use and fairly complete.)

However, I would love to see more competition. libghostty is useful and good, but I think it's possible to create a better library for the underlying state machine—better from a performance, code quality, and design perspective. Furthermore, there's still a lot missing from libghostty, namely supporting functionality. That is, the proofs-of-concept that I was able to create in a couple hundred lines of Zig could have been even shorter, if I did not have to write some minimal helper libraries around the edges of the state machine. (To be fair, some of the helper libraries cover gaps in the Zig standard library—e.g., conveniences around system calls like fcntl or ioctl…) In fact, there may be even be a way to design the state machine API such that we can address complaints about common tools like terminal multiplexers.

It's hard for me to judge the risk of a monoculture evolving around Ghostty. On the one hand, Ghostty is “where the action is,” and we shouldn't extrapolate too much from this. On the other hand, there is a pervasive feeling that programmers have become hesitant to invest in creativity, novelty, or design, because so much work can seemingly be accomplished without such cost. It's very hard to predict what the consequences of Ghostty development being pulled into the efforts of a start-up company developing what appears to be LLM tooling.

We know that consolidation can occur very rapidly in some circumstances, and they look like those we currently inhabit (e.g., your coworker whose argument is “well, that's what they're trained on,” when advocating against adopting new technologies,) but diversification can also occur very rapidly in circumstances that also look like those of the day (e.g., your other coworker's counterpoint that the bulk of the tedious effort involved in adopting some new technology can be done at very low cost.)

Terminal emulators have historically evolved very slowly, and this conservatism obviously has upsides and downsides. Many of us have come to terms with or have found coping strategies to mitigate the downsides, so we experience the conservatism as mostly a positive thing, preserving a useful, working environment. (As another comment here states: “terminal emulation is already way too complex.”) This more rapid evolution may seem disconcerting, but I think it's worth considering the goals of the kitty terminal protocol extensions:

The goal of these extensions is to be as small and unobtrusive as possible, while filling in some gaps in the existing xterm protocol. In particular, one of the goals of this specification is explicitly not to “re-imagine” the TTY. The TTY should remain what it is -- a device for efficiently processing text received as a simple byte stream. Another objective is to only move the minimum possible amount of extra functionality into the terminal program itself. This is to make it as easy to implement these protocol extensions as possible, thereby hopefully encouraging their widespread adoption.

Considering this, I think there's a case to be optimistic. If the evolution of the terminal protocol is as deliberate, as considered, and as thoughtful as this goal suggest… then maybe we'll be okay?

As restrictive as using ASCIIUnicode art for drawing minimal outlines in terminal output, they have one big benefit. This cell border feature has the same drawback as leveraging colors for differentiating sections of the output. It breaks copy/paste by losing semantic info that might be needed.

Looking at something like rustc's output, we could make the gutter where the line numbers are be one to two cells smaller by using a different background color, but then copying that or using NO_COLOR would make the output no longer look as easy yi glance.

For TUIs that drawback is less pronounced because most people don't expect to be able to copy the app's output, and the app can detect that it is in NO_COLOR mode and change the rendering.

I like the idea!

The log example's borders touch the text which is looks pretty bad IMO, and might make reading harder depending on the language.
I wonder if the protocol can mandate a visual separation.

I love this!

Does it fail gracefully in terminals without support and just not render the lines?