Terminal borders that don't cost a cell

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?

▲

unshavedyak 11 minutes ago | parent | next [-]

I actually am exploring exactly this. Ironically from the perspective of someone that was trying to leave the Terminal.

How i got here i find kinda interesting. Originally i was trying to leave the terminal. Using GPUI/etc frameworks. I kept running into the terminal though, because no matter how nice the UI is - the terminal still needs to work excellently.

Eventually i decided to try an abomination, to use a custom terminal which, not unlike Kitty images, allows generic apps to pass escape codes to control the UI components. Where the UI components have no restriction on "dumb terminals". So my text editor is a two part app, an editor and a tty to render the actual custom UI APC codes.

This paved the way for true smooth scrolling from within a terminal editor, as the editor effectively paginates but the tty scrolls within the buffered pages. It allows for different UI components to mix fonts and font sizes, eg popup docs being a different size than the other text, and .. well, anything i suppose.

I have to say it's working excellently and is slowly becoming my daily driver. I won't link it though, it's a fully vibe coded and even claude designed horror.

I'm surprised i've not seen more of this in the past to be honest.

▲

hedgehog 31 minutes ago | parent | prev [-]

Text terminal with every keystroke round-tripped through the server is not a design that makes sense for any reason other than backwards compatibility. It's kind of annoying to design for and atrocious for performance.

	▲	toast0 5 minutes ago \| parent [-]
		Teletypes and dumb terminals managed to implement local echo. You don't need to round trip everything.

▲

joouha an hour ago | parent | prev | next [-]

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

	▲	hnlmorg an hour ago \| parent [-]
		I’m not against overstrike, but I can think of one drawback of that solution: it becomes significantly harder to have rounded corners with a filled interior. But I’m not trying to argue for nor against either solution.

▲

ganelonhb 2 minutes ago | parent | prev | next [-]

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

▲

montroser an hour ago | parent | prev | next [-]

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.

▲

hnlmorg an hour ago | parent | prev | next [-]

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.

▲

cobychapple an hour ago | parent | prev | next [-]

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

▲

0c3ca83 an hour ago | parent | prev | next [-]

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?

▲

rvz 28 minutes ago | parent | next [-]

Honestly why? It is not designed at all for that.

In fact it just makes it less secure.

▲

drdaeman an hour ago | parent | prev [-]

> HTML

> instead of hacks on top of hacks

Afraid that’s a contradiction. In this role, HTML is a pile of hacks upon hacks that was not originally intended for UIs.

But, yeah, people are trying to reinvent GUIs. By layering hacks over TTYs. If only there’d be some protocol for widgets and events over a stream connection…

▲

masfuerte an hour ago | parent | next [-]

While we're figuring it out let's call this hypothetical protocol X.

▲

ncruces an hour ago | parent [-]

We could even use `ssh -X` to send it over SSH if that flag is otherwise unused.

	▲	cluckindan 21 minutes ago \| parent [-]
		I think it would make sense if it had a client-server architecture.

▲

em-bee 7 minutes ago | parent | prev [-]

plan 9?

▲

kenzo_cavanaugh an hour ago | parent | prev [-]

[flagged]