Terminal borders that don't cost a cell

A much better alternative to this would be to for more terminal emulators to implement overstrike mode (DECSET 20, as available on the VK100). That way you could just draw border characters over existing text cells to achieve the same thing.

Unfortunately mintty is the only terminal emulator I'm aware of which supports overstrike [0], as this would open up a world of new possibilities for TUI apps if more widely supported.

[0] https://github.com/mintty/mintty/wiki/CtrlSeqs#overstrike

I love this work and everything else Ratatui does but I have to ask: if you're changing the terminal protocol and the terminal itself to do this, why not do something more ambitious; a full monospaced information-dense UI framework, a terminal designed for user interfaces, rather than one designed to replicate the limitations of dumb terminals?

This is pretty cool but this does feel like we are just reinventing another GUI display at this point.

I don't generally like TUI's and think one gets more flexibility with raw text interfaces and being able to glue things together is more important then them looking nice. I think less fancy out put is better to be honest.

Didn't read the post but two observations:

1. The AI disclosure up front is very useful for cutting my blog filter time from 10 seconds down to 1, which is significant in the age of content overload. Hopefully disclosure becomes a point of pride for vibebloggers and they'll add it more often.

2. While it makes sense that the popularity of TUIs (driven mostly by CLI coding agents) sees maintainers try and push more spec into emulators, I'm hoping this doesn't become the standard. The whole TUI mentality just runs counter to what makes terminals such sticky tech in the first place.

What worries me is that TUI used to mean light on your hardware unless it's doing actual work that you demanded.

What's the reality with these new frameworks? Whenever I see one i worry that it renders at 144 Hz in a loop instead of redrawing only when something changes, for one. And let's not mention redrawing only the areas that have changed [1].

Should I ask about ram consumption too?

[1] ... which is why vi is the best editor to use over slow, unreliable links.

As awesome as this is, but I can't shake the feeling terminals are becoming lightweight browsers...

I like the approach Norton Utilities for DOS took. They used a custom font to change the block drawing characters, so that the lines were not in the center but at the edges. That allowed very clean looking layouts. They even created a pixel-perfect mouse cursor in text mode by constantly redefining the cursor characters to include the unterlying text. Unfortunately the Norton style box drawing characters are not part of Unicode (yet?)

I'm all in favor of compact displays; and these borders are much nicer than the box-drawing characters.

But... "nicer than box-drawing characters" is such a low bar. The semigraphics are right there, and can be beautiful! They've been part of DOS (cp437) since the very beginning, and Unicode has a more-than-adequate variety.

Here's my afternoon's experiment: `prtty`

https://github.com/hughpyle/prtty

I appreciate the innovation happening with TUIs in these modern times. But, aesthetically, I have to say, I like my borders to have some breathing room, which gets lost in this particular treatment.

Compatibility will always be the hard part with new standards like this. Given that most terminals already have some special handling of box drawing characters, I don't know if it's completely dead on arrival for implementors, but I don't love as an application author with ratatui, not knowing how the padding on my app will look. I might honestly rather disable this and know it'll be more consistent, than enable it and fragment my UI.

Seemed like an interesting idea so after some sanity checking decided to see how feasible this would be on kitty.

Interestingly enough the kitty author has declined a feature request similar to this couple years ago in https://github.com/kovidgoyal/kitty/issues/7511 but the approach here seem to have not resulted in any of the major pains he was expecting in that message. It is valid point that implementing something like this on a single terminal might not be worth it, but now we have poc available for two major ones I guess?

Anyways, branch and write-up available here: https://github.com/errnoh/kitty/blob/cell-borders/CELL-BORDE...

(The usual disclaimers apply: all of the actual code is AI written)

I grew up on the Commodore 64. This machine had not enough resources to do much with its graphics modes so essentially the usual way to use it was text with custom characters plus sprites [1]. I think text base plus overlay is an incredibly powerful combination.

A while ago I coded this up with a Ratatui subset on the Commodore[2] but I think this paradigm could be useful for modern TUI apps as well. One example I'd use that for is a minimap, which is quite awkward to do in characters.

[1] Plus the occasional whole screen offset and raster effects.

[2] Code is not public yet but there is a screenshot how it looks. https://github.com/weinzierl/8-bit-rust

I like this a lot, especially the ability to draw lines through graphs like in `btop`.

Somthing I think could be intresting to go along with this is for the terminal to be able to distinguish sub-windows using these border, so if you've got a popup and try to select multiple lines in it, you'll actually select only the text in thr popup rather than the whole terminal-wide line.

I'm wondering for some time now, if it wouldn't be better to define a new terminal standard from scratch. Something that can be automatically detected and switched on once both the application and the terminal emulator support it.

Instead of adding extension over extension on top of some old protocol. And using a lot of hacks to get stuff done.

Would be cool to get borders and lines out of copy/paste

Why wouldn’t this work over tmux? The authors claims don’t make a whole lot of sense because if this were a cell property, like any other CSI, then it’ll get rendered in the terminal emulator exactly as intended. And we know this because none of the other CSI sequences get garbled over multiplextors.

But for there to be a dedicated section on how multiplexors wouldn’t work suggests to me that the authors already tried this via tmux.

So I’m left wondering what they’ve done with the implementation of this to make that a problem.

I spotted they are using DCS sequences. But even that shouldn’t be an issue itself.

I am in general against the big push to fit GUI interfaces into the tty, but I have to say that this feature looks genuinely good. Vim will look great with this.

The big thing to note on this is one last caveat. I don't care about the actual spec on this - happy for that to be whatever works. I care more about the capability than how it's done / implemented.

There's some bits that feel like they probably make sense to consider doing other ways, like how border placement works (inside, outside, on the border, etc.), and how the filling works - to make borders incorporate external or internal padding.

Interesting. All I wish I could do in a terminal is moving the cursor by clicking. And maybe selecting some text and replacing it with a single key stroke. Why is that not a thing?

I used to not understand why there are so many little perks in the terminal - until I started spending quite a lot of hours a day in the terminal.

For some reason the page has very few examples of left/right zero width borders. The only ones I could find were a checkbox and as a highlight to show a selected row in a list.

Is it because it looks visually crowded?

I kinda like the examples without the native borders…

The charm of the terminal is that you can do whatever you want, as long as it fits in one cell.

I just wonder why Claud code to ever other CLI is still in JS? Why not Rust? I mean - how much effort it would be to port all the libraries? With AI?

Looks very nice! But what about a terminal overlay in general?

It reminds me of video games overlays / layers (like the gameboy window layer) used to display HUDs.

neat! but, so, for borders around button text, rightmost border terminal sequence would have to be inserted before the last char, right?

[background color, top, left, bottom]B[top, bottom only]UTTO[top, bottom, right]N[reset]

Before I clicked I interpreted the title as airport terminals whose border controls don't require a burner phone.

Terminal is tempting, but I encourage ppl on herdr to give T3 code a try, gui is so much nicer to use for prompting at the least.

There's a nice thread about this on lobsters, but the author is getting piled on.

I like this idea! Of course I might be biased, since it’s similar enough to one I’ve had myself. Good job getting an implementation going; I never did.

I like it. As an analogy, borders are important features of spreadsheet tools as well.

Love this. And the people who like more space can opt for that (this doesn't look things in).

This is gorgeous and I need it in trunk for both kitty and ghostty

Thanks for that slop warning, on a general point: wondering whether there might be enough momentum to finally ditch the whole terminal garbage and use proper GUIs in spite of what the card-punching devils intended?

Unpopular opinion: I’m not interested as a user.

I like simple, predictable TUIs which i can operate with keyboard input only. I don’t like ui chrome or complex ux in TUI, i prefer GUI for that.

I love this idea. I HATE looking at rounded corners in the terminal window. Hate. I had no idea I would feel so strongly about such a thing. Also, easily fixable. But, wow.

Why do you people have to ruin terminals? If you wanted a web browser, we already have those, and they already have borders.

How much RAM does this use?

> If that bothers you, feel free to close the tab.

I probably missed on something, but I stopped there

What if, dare I say it, we just served HTML over ssh, and let the browser render a proper UI, instead of layering hacks on top of hacks?

I like it

Having markdown tables render with zero-cell spacing (use underlines for horizontal and different background shades for vertical) is just one of the billion reasons I will never, ever, ever go back to closed-source coding agents.

“….that don’t cost a cell.” How much do I hate AI hustle bro passive riddle writing.

A pet peeve of mine is that most people / WM get "useless gaps" wrong. You do want a gap between two terminals because otherwise there are times where things can get really confusing (where you don't know what belong to which terminal / window).

So the "borderless" (0 pixels) / zero "useless gaps" simply are confusing and... Wrong.

But then people who do use useless gap, as in TFA, get it wrong too: they typically add gaps near the monitor's edges.

Yeah. But no. Sorry but my monitor's edge is a perfectly fine gap. I don't risk mistaking it for anything.

So I modified my WM (the Awesome WM) to do proper "useless gaps" computation and remove the ones that really are useless: and that'd be those near the monitor's physical border.

I mean: nearly everybody gets it wrong, but it's not complicated to get it right, is it?

P.S: even the terminology is wrong... People calling those "useless gaps" haven't got a clue: they are useful. The only useless ones are the one on the monitor's edge (if your monitor has physical edges, which it probably does).

“That don’t cost a cell.” Can’t stand AI bro speak.

One benefit worth calling out: the box-drawing fallback is worse than it looks for CJK users. U+2500-257F and the half/full block elements are East Asian "Ambiguous" in UAX #11, so in a terminal configured to render ambiguous as double width (xterm's cjkWidth, iTerm2's checkbox) every line glyph takes two cells and the whole frame lands in the wrong place. Cell borders aren't text, so that failure class just disappears.

The part I'd want specced early: borders are per-cell, but cells aren't per-grapheme. A CJK char owns two cells plus a continuation placeholder, and combining marks or ZWJ emoji sequences own zero-or-more depending on whose wcwidth table you ask, so app and terminal routinely disagree across Unicode versions. Today that shows up as a vertical bar one column off; with cell borders it becomes a line that stops short of the corner. Does the border attach to the cell or to the grapheme cluster?

[flagged]

[flagged]

[flagged]

[flagged]