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 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.

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

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?

[flagged]

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

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?