Rendered at 05:16:26 GMT+0000 (Coordinated Universal Time) with Cloudflare Workers.
joouha 1 days ago [-]
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.
Ages ago I had found a software that would convert an image to ascii-art, and then used another tool called posteriza to split the large image into several A4s, which I then taped together and hung on my wall. Would love to do something similar but with better tools.
Yessss! Thank you for sharing, blast down memory lane!
NetOpWibby 15 hours ago [-]
Pretty cool method doing “shading.”
Sharlin 16 hours ago [-]
A considerably less archaic and more generally useful way would be for Unicode to add border-drawing given that the concept of composing several codepoints to the same glyph is already there and ubiquitous. You’d just need 2^4=16 new codepoints.
graypegg 13 hours ago [-]
Unicode is a lot more concerned with what a character means vs how it displays. The box drawing characters that have codepoints are there because they were part of some device's proprietary text encoding, so it's put in a codepage somewhere so a document from that device could be used on something else given it gets converted to unicode.
Pretty unlikely they'd be into adding a new ZWJ pattern for bordering characters since it's awful given unicode's main goal is interoperability. If you copy text out of your terminal, those characters come with it and probably won't render correctly in non-terminal applications (which don't have monospaced text cells), so you'll just see the ? missing character symbol between every letter. (Possibly overstruck onto the previous character depending on handling for the ZWJ.)
I guess the other way to look at this would be "should the background colour be a unicode ZWJ pattern?"... probably not. The border (and colour) is a property of the terminal cell rather than the actual characters IMO. It's not like `X + ZWJ + LEFT-BORDER` has any unique encoded meaning. Cell attributes like the article is talking about IS the less archaic way of doing this. ZWJ patterns are a lot more archaic and cause a lot more issues. Overstrike is fine, if it's being down with cell attributes (meaning, moving the cursor overtop of a cell, and stamping a new character on it instead of replacing it. Exactly how mintty does it.)
lenkite 46 minutes ago [-]
> Unicode is a lot more concerned with what a character means vs how it displays
This was only true before emojis. Unicode introduced specific code points purely to alter visual display, such as skin-tone modifiers, etc. Now that the mission was already diluted for emo-fluff, you might as well add actually useful fluff.
The ones they DO let through, must have some sort of useful distinction in meaning to be given a code point(s). It can't just be useful as a little image of a thing. It has to provide some sort of linguistic concept that extends the emoji... language? https://unicode.org/emoji/proposals.html#factors_inclusion
The skintone modifiers are meaningful because it can look more like someone you're talking about. "S with a left border" isn't disambiguating any sort of meaning from "S with a bottom and right border".
joshka 5 hours ago [-]
This is not as bad an idea as it would seem, but it's never going to happen with Unicode. It could reasonably happen with a combination of NerdFonts / private area shenanigans + cell rendering on the terminal side of this to handle it.
It solves the z-index problem neatly for an individual cell as you just render in order (first underneath, second over the top). But it doesn't solve the order for adjacent cells - borders that lie between cells. At least not easily. Not an insurmountable problem.
Some perspective if you're unaware. Fonts have the unicode line drawing characters, but fonts don't align super well and so a good terminal will draw those characters with line drawing algorithms instead of as a font. I've got a WIP PR that I need to land in VSCode's that pulls in xtermjs and ghostty's line drawing stuff so that it fixes up all the existing gaps on that as an example of this problem.
binarymax 16 hours ago [-]
Oh like a diacritic? Good idea.
Sharlin 15 hours ago [-]
Yep. And actually you’d only need four codepoints (per line style) because you could just chain them to get a line on more than one edge.
graypegg 13 hours ago [-]
I'm iffy about that. If you copy/dump text out of a terminal, what characters do you get for the doublestruck cells?
Plus, just complexity wise, I'd much rather just have a DCS sequence to draw vector lines like the article's suggestion than first send all the borders then home the cursor, send the overstrike sequence, send all the content, send the overwrite sequence. That has so many more places where a session gets trashed by accidentally sending the wrong control character.
unleaded 9 hours ago [-]
I always find it somewhat amusing that most modern terminal emulators don't actually do a very good job of emulating terminals. IIRC Windows Terminal supports a lot of DEC commands that most of the terminal emulators on Linux don't!
hnlmorg 1 days ago [-]
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.
benterris 20 hours ago [-]
How is it harder? If I understand correctly overstrike is a superset of the regluar 1-char-per-cell mode, so nothing is lost by going overstrike?
hnlmorg 20 hours ago [-]
Because the background colour isn’t bounded by the border colour using overstrike, but it can be when using borders.
This isn’t an issue if you want square borders. But the screenshots in the article showed fancy rounded corners.
CSI 53 m SGR 53 — Overlined
CSI 55 m SGR 55 — Not overlined
which is much more different than mitty's Control Sequence, but supports much more emulators
__alexs 17 hours ago [-]
More terminal emulators should implement Tek4010 mode and just draw vectors everywhere.
graypegg 12 hours ago [-]
I mean X is just sitting there with an extra decade or so of modernity. (Or Wayland for something MUCH more modern) Imagine ssh-ing into a server, starting an application, and a GUI application window appears. 1990's finest technology is awaiting it's rediscovery here in 2026.
cowlevel 19 hours ago [-]
The better alternative to most of this is to use a different display protocol, one that gives you pixel-level control, if you want pixel-level control.
qudat 10 hours ago [-]
Now we are in GUI app territory which is why I don’t like this terminal proposal or even kitty gfx. The terminal should be about text processing and at most a 2d grid of cells. Once you start talking about pixel buffers replacing cell buffers I fear we have lost the plot.
alpaca128 15 hours ago [-]
Can you name one which is as lightweight and simple to use as terminal escape codes and supported by almost any platform with a screen and keyboard?
kergonath 11 hours ago [-]
Sixel could be, but it’s not as widely supported as I’d like. But even though it could be used much more, I think the borders in the story would be very useful, and I hope something like this gains traction.
cowlevel 13 hours ago [-]
Yeah, X11.
You might think it's a bit complicated, but I counter: so are terminal escape codes.
0c3ca83 14 hours ago [-]
HTML.
alpaca128 10 hours ago [-]
I was talking about native applications, otherwise there would literally be no other choice than HTML anyway.
oblio 18 hours ago [-]
This protocol would still be used for user interfaces, but it would use a completely different approach to rendering them, I guess we could call this approach "graphical"?
joshka 1 days ago [-]
There's some downsides to this - I can't recall where I called this out off the top of my head, but this also adds a bunch more things that that wouldn't do that are covered in the spec.
iainmerrick 1 days ago [-]
If you mean your proposal adds more things, that sounds like it might be over-complicated. To solve the problem of tightly-fitting boxes around terminal text -- if you consider that to be a real problem -- overstrike sounds like a really elegant solution.
joshka 1 days ago [-]
Which things do you consider in your experience of writing tuis that are mentioned as being wanted in the blog post / rationale doc linked to be unnecessary?
If you want those things then overstrike is insufficient.
zem 1 days ago [-]
cell borders sound even more elegant imo, they are a targeted, precise fix for a useful feature. overstrike sounds messy to me though I can see where it has a lot of uses.
muqsitnawaz 1 days ago [-]
Expecting Terminal Emulators to support overstrike is a high bar even many text editors don't even support strikethrough. Would love to see it though
thiht 21 hours ago [-]
What makes it much better?
20 hours ago [-]
db48x 23 hours ago [-]
Overstriking support might be nice, but it wouldn’t help much for this use–case.
joouha 22 hours ago [-]
If it's not obvious how this could be achieved with overstrike, basically the idea is that you could draw text on a cell then overstrike the cell with 1/8 block characters for the 4 edges characters (U+2581 & friends) to create a border around the cell.
Edit: HN stripped the characters in question from my comment
db48x 5 hours ago [-]
That’s really crude, so it wouldn’t help much for this use case.
tptacek 1 days ago [-]
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?
joshka 1 days ago [-]
Yep,and I want to do that too :)
I've written about it before, but in brief the mountain of standards is worth ripping out wholesale and doing write as a semantic protocol. It's needed to solve several things that work really poorly in terminals because their unit of compatibility is cells rather than a higher primitive. It's hard to bake something on top that works well.
The need is most strong in Accessibility, Text wrapping, Scrollback handling (i.e. making the scrollback editable and not dead text), and various other bits that make writing highly functional TUIs. Coding agents tend to find all those edge cases.
This often gets push back that it's easy, to which I can point nay sayers at the various many months long issues on things in Codex, Gemini, Claude etc. on flickering, scrolling, key handline, IME, ... doing anything moderately complex involves modeling a terminal in a terminal app effectively.
Ghostty and Rex sort of do the opposite bit. If you think of it like a stack, they write a new layer underneath that transports the cells on a better multiplexer layer 0. I think a new semantic layer 2 is an approach that would be neat to work with.
tptacek 1 days ago [-]
I think I mostly just want to see someone do it so I can see what it looks like; it just feels like something that should exist. You're taking baby steps towards it! :)
joshka 1 days ago [-]
I kinda keep talking about it in the hopes that someone will be nerd sniped enough to throw tokens at it as an idea. Sort of what you're probably doing too I guess. ;)
qudat 10 hours ago [-]
Ive been iterating on this idea for a few months now and dont want to divulge too much but ill tease it here: everyone is trying to rebuild the multiplexer but are doing it using the in-band ansi bytestream.
Fundamentally this is the wrong abstraction and it is painful to develop modern terminal features on top of it.
We need a terminal compositor protocol. We need to leave the pty behind and replace it with a unix socket. What other compositing protocols exist in the modern tech stack that we could extend?
Anyone can feel free to reach out to me if they want to chat about it: https://bower.sh
joshka 5 hours ago [-]
> We need a terminal compositor protocol. We need to leave the pty behind and replace it with a unix socket. What other compositing protocols exist in the modern tech stack that we could extend?
I think there was some discussion about this last time I mentioned the idea on hn a few weeks / months back. Trawl my history to find it pehaps.
josephg 1 days ago [-]
... Write up a more complete spec of the problem and I could be tempted to throw some tokens at it. But before I do, can you write up a more complete description of the problem with existing terminal protocols? I don't think I understand the issues well enough to make a good solution. Eg, can you give some examples of what apps are hard to build now? What prior art is worth looking at? Etc.
joshka 4 hours ago [-]
The big ones I see are:
- When you write cells, you don't have an area of the screen that you can treat as the current area, which makes screen readers have to treat the screen as characters and recompose those back into words to read. You lose any rectangular area concept and treat lines in the terminal as lines that the screen reader reads. Semantically you throw away all the layout information by writing to the terminal.
- When you write stuff to the screen and then write enough lines to the screen to push lines into the scrollback, you lose the ability to change those lines in future. You can move the cursor anywhere in the screen viewport, but not anywhere outside of it. Scrollback is dead text once written there. This is fine for most apps that need append logic, but less so where you have reasons to treat the terminal as a space where you update it or gain access to things like expanding info. e.g. pick up claude code or codex and think about how you collapse a diff or command output to headers and then expand it, in the viewport, not a problem, in the scrollback it's dead text written once.
- There's a mismatch in the way that wrapping works when applied to the screen. If you're wrapping text at the screen boundary, and letting the terminal select across lines, it hits the edge of the terminal, and wraps to the next line. There's no concept of the edge of a block, because cells are the base level primitive. This affects selecting text, copying it, etc.
- Resizing terminals after stuff has written requires repainting the existing screen and then taking care about what was written to the scrollback history. E.g. if you have 200x50 and resize to 200x49, the top line just entered the scrollback and is now part of the history that you can't edit. Unless you clear the entire scrollback and repaint. Again similar problem and reasons. Resizing to 199x50 is worse, because you lose a character on each line, and push stuff into scrollback. And also the opposite 200x51, you just pulled a line from the scrollback now, so now you have to consider what to write back to that line later - what was dead is now alive again. These problems make writing terminal coding agents that rely on having interactive parts of the screen and history parts of the screen tough.
- Scrolling in general. If you look at how each terminal scrolls, and how many lines it maps to each mouse scroll wheel action, it differs per terminal, and it differs based on mouse / trackpad use as well. The events you get are not standardized in count, frequency, acceleration, ... This makes doing anything related to scrolling when you own the entire screen and scroll state a pain as you're trying to emulate the terminal's native feel and that differs a bunch. So there's a strong missing abstraction over scroll state things instead of just plain mouse events. Having a terminal and app level collaborate to tell where the scroll is up to is the approach that seems to be necessary here.
A lot of this comes from the fact that terminals are a mix of standards tracing back many years, stacked on top of each other, implemented poorly or not at all, ECMA, VT, DEC, iTerm, Kitty, OSC, ASC, DCS, SGR, ... and they all deal in cells being the basic primitive rather than the higher level semantic thing you need to do a TUI that is region aware. That's a impedance mismatch that is hard to bridge without a new standard that just sidesteps it completely.
If you look at the history of Codex / Gemini / Claude Code, they've each run into this problem a bunch over time and solved various bits of it / ignored other bits of it.
kalaomer 1 days ago [-]
I've been working on one version of this, if you want to see what it
looks like: https://bateri.dev/pens
It's narrower than replacing the cell grid. A program asks for a view
the way vim takes the alternate screen. If the terminal answers, the
program hands it the view's files once, and from then on the two
exchange six small messages inside the normal byte stream (APC frames,
the same trick kitty graphics uses). No port and no extra connection,
so it works over plain ssh to a box with no GPU. When the program exits
you get your terminal back, and in a terminal that doesn't answer the
program can fall back to plain text.
A view is either a Lua script the terminal draws itself, in its own
font and theme, or a sandboxed web page. The second one is exactly the
"terminals are becoming browsers" worry from upthread, and I don't
think that worry is wrong, which is why the native kind exists. Going
through tmux is a non-goal: a multiplexer that doesn't pass the stream
through untouched just means the program sees no host and falls back.
I'm so happy to see someone also recognize that cells are holding terminal back.
nottorp 20 hours ago [-]
> Coding agents tend to find all those edge cases.
Do they? Last time I checked you still couldn't select text via the keyboard in the Claude Code TUI.
joshka 4 hours ago [-]
By "find", I meant "expose" - i.e. terminal coding agents tend to make these flaws evident because they're trying to do the right combination of things in the TUI where there are painful annoyances and tradeoffs that can't be easily resolved at the application level.
oblio 18 hours ago [-]
It's amusing that the flagship products of the post-2023 AI era can't fully handle 1972s teletype interfaces :-)
fc417fc802 1 days ago [-]
> a full monospaced information-dense UI framework, a terminal designed for user interfaces, rather than one designed to replicate the limitations of dumb terminals?
I can only speak for myself but I use the CLI and TUIs specifically because of the limitations those modalities impose on software that uses them as the primary method for interfacing with the end user. If you want a full featured UI and all that comes with it why not just use QT or GTK or modern HTML or etc?
I think the only "improvements" I'd like to see are thing such as metadata regarding what the different streams are for, an official way to communicate using structured data as opposed to raw bytes, that sort of thing. Spiritually in the same ballpark as the difference between HTML before and after CSS.
unshavedyak 1 days ago [-]
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.
kodoman 1 days ago [-]
I am running ewm (not exwm) which makes emacs into a wayland compositor and it's fantastic, most of the primitives dissolve and you script it with elisp, wayland windows are just a special buffer and where applicable normal windowing and buffering rules can be applied.
The developer seems to have used AI heavily in the elisp code and it works very well.
> To use a custom terminal which, not unlike Kitty images, allows generic apps to pass escape codes to control the UI components.
> I'm surprised i've not seen more of this in the past to be honest.
This is what emacs is. It's a text buffer, but text can have properties like how to render, and custom values. then a bunch of commands to manipulate the buffer and it's contents.
unshavedyak 13 hours ago [-]
Funny you say that, i had always wondered what Emacs was - i should have followed that curiosity at some point. It always looked like a standard TUI, but i thought it required its own executable.
I'll look into that, thanks!
octoberfranklin 1 days ago [-]
Because it will turn into the kitchen-sink mess that the Web is.
Terminals work so well because there's a huge frictional cost to adding to the protocol. That's what keeps the protocol simple, which is what keeps multiple implementations feasible. Unlike the web, where unless you have GoogleBux you can't afford to implement it properly.
tdgunes 19 hours ago [-]
Whenever I use dumb terminals, I have the same feeling. I am also actively looking for a way to get a good developer experience while keeping more ownership of what gets generated with the new tools. My specific bottleneck is working in remote environments and not being able to have it , now that we have tools like Claude, Codex, and Gemini. (I find them safer to run them in virtual environments and working on them remotely is better than doing it locally.)
I also don't like the fact that each TUI application (btop, for instance) comes with its own color palette. So, a friend of mine developed a terminal (https://bateri.dev, macOS only for now, but the plan is to port it to Linux later) and yet another protocol where terminal SPAs can communicate over standard SSH (inspired by X over SSH, but we didn't like its drawbacks). The SPA itself is a set of Lua scripts that runs in a sandbox inside the terminal. The application on the host that communicates with the SPA can be implemented in any language (preferably Lua to keep it simple). With this approach, all SPAs (plugins) adhere to the user's color palette preferences. (There are more details that can share if you are interested.)
So far, to stress test it and help with devex, he has built a text editor (https://github.com/bateri/textpen) and a Docker/task monitor (https://github.com/bateri/dockerpen). I am also working on a plan document viewer that works within the terminal. We'd love some feedback if you are interested.
kccqzy 1 days ago [-]
You can save all that effort and instead come up with a CSS framework that enforces monospaced fonts, uniform font sizes, encourage information-dense layouts, have borders that don’t take up a cell (border: solid 0.1rem black; padding: 0.5rem;). Pair it up with a small JavaScript framework that listens to keypresses and buffers them. Furthermore, the framework makes the user decide on fonts, whether to allow images, whether to adhere to a strict character grid etc.
In other words you want a library that wraps X11 and displays a character grid in a monospaced font.
eviks 1 days ago [-]
Or even more ambitious - ditch the monospace
joshka 1 days ago [-]
For a while in the 2000s I tried programming with Verdana in my IDE at the time. It wasn't all that bad. It would be in a terminal however - fun idea regardless.
nepthar 1 days ago [-]
Have you tried this? It’s awful
eviks 1 days ago [-]
Tried what? It's not supported now, everything is a fixed grid
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 1 days ago [-]
Teletypes and dumb terminals managed to implement local echo. You don't need to round trip everything.
kodoman 1 days ago [-]
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.
acjohnson55 24 hours ago [-]
I completely agree.
If we must embed 2D interfaces in terminals, I feel like we'd be better off putting in iframes or canvases that occupy a dedicated rectangle of cells.
petesergeant 23 hours ago [-]
Everyone has different priorities. For me, the main benefit of the TUI is the brain-dead ease in which I have windowed applications running over SSH.
timhh 20 hours ago [-]
I have vibe coded a remote X/Wayland solution that actually works really well for this, at least as long as you are mainly interested in one machine (so good for people with remote work machines, not so good for network/infra engineers).
You just run `mycommand connect host` and it will connect via SSH, start a Wayland server with X support, set up the appropriate environment variables, and also automatically reconnect, so you only have to do this once.
After that you can just run GUI commands via SSH and appear locally like you always wished they would. It uses a VNC-like image data protocol so the client works on any OS. And windows are seamless - no windows within windows nonsense. I haven't put much effort into the video protocol tbh but it's already better than Xpra and very usable with 100ms latency (London to NY) so that's good enough for me.
I'll try to open source it.
I think a better solution would be if SSH itself supported some GUI channel, but the only thing is the Kitty graphics protocol which kind of sucks tbh. I did try writing some tools using that for the GUI a while back but it's awkward because you have to use PNG, you're still stuck with the character grid for text, etc.
tdgunes 19 hours ago [-]
100ms sounds good, but how about the consistency of the GUI (remote vs local) and HiDPI issues when it comes to this approach? (I assume latency would be higher when there are many applications running in many windows?)
timhh 15 hours ago [-]
To be clear I meant the experience is fine when running on a 100ms link. I haven't measured the actual latency. That said it uses QUIC and sends the data as tiles, which are displayed immediately, so I suspect it is basically as low latency as possible. It does lead to fun mosaic style tearing which half of me finds cool and half wishes it didn't do that, but side-by-side with Xpra it's much faster and less annoying than waiting for a whole frame which is what Xpra does.
I'm running an old Qt X11 app with a modern retina MacBook with multiple different density screens and it works fine. There were some minor issues with that to start with but I pretty much just said "this happens, please fix it" and Claude figured it out without even having access to a Mac, which is impressive.
Honestly the thing that was hardest was keyboard layout. That kind of stuff never worked well for me in any remote desktop app, and now I can see why! You might never notice if you only use the US layout tbf. It works pretty well now though - I got it to query your local layout and the dynamically build an X keyboard layout and send it to the server.
I've run it with up to about 4 large windows and it seems to work fine. It doesn't send anything when nothing is changing so lots of windows won't matter unless they're playing videos or whatever - it's more designed for old Windows/Qt/Gtk style apps. I suspect you could do better with a traditional video codec but unfortunately the server I use has no GPU so that wasn't really an option.
solyin 20 hours ago [-]
Fwiw, openssh can be used as a proxy to shuffle TCP packets around. You're not strictly stuck to using a PTY. A modern xpra would be amazing!
cowlevel 17 hours ago [-]
ssh -X (or -Y) forwards your X11 connection automagically. It doesn't work for Wayland because Wayland was designed to be impossible to forward.
However, most X11 apps will have utterly abysmal performance on WAN SSH connections. Ancient apps will be slow because they block waiting for every response (this is unavoidable in Xlib) and less than ancient apps will be slow because they send full pixel data. It is possible to write a reasonably performant remote X11 app (using XCB instead of Xlib and always being aware of latency), but there are very few such apps. This is why Wayland dropped the requirement.
dale_glass 16 hours ago [-]
For Wayland forwarding, there's waypipe.
cowlevel 17 hours ago [-]
Then we need a way to run GUI applications over SSH with the same ease.
There used to be one. It was called X forwarding. You'd run ash -X or ssh -Y and it magically worked.
cowlevel 13 hours ago [-]
typo correction: ssh -X or ssh -Y
fodkodrasz 22 hours ago [-]
ssh -Y worked well for me. That usecase should be revived in a bandwidth efficient manner (eg. RDP does bearable over crappy links, eg. over the ocean) instead.
user-error 16 hours ago [-]
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.
teo_zero 12 hours ago [-]
1. I doubt anybody on HN has any interest in what your personal criteria are for reading blogs. Please, please, please let's stop polluting the comments with arguments about how a piece of software was made instead of about the thing itself.
2. I agree if you refer to TUIs that try to emulate/substitute complex GUIs, with sub-panes, dialogs, graphics, etc. I happen to love TUIs for simple text-only visualizations, though. They are usually quicker than GUIs and consistent among various OS, desktop...
kuschku 12 hours ago [-]
> Please, please, please let's stop polluting the comments with arguments about how a piece of software was made instead of about the thing itself.
But it IS relevant how something was made! It tells us how much of the detail that's presented in code & blogpost is the authors intent, and how much of it is "filler". It tells us whether the author can answer detailed question as to why they chose a specific implementation, or novel technique, or not.
It tells us whether the author wants us to read every syllable, or whether readers are expected to let their own summarize the article for them instead (as would be the case here).
It's never worth it to spend more effort reading something than the author spent writing it. The important part is the human intent, not the filler surrounding it!
teo_zero 11 hours ago [-]
Your reasoning could be applied word by word to the latest novel by Stephen King. I may know that it has been written by an army of mercenary ghost writers and nonetheless enjoy it and warmly recommend it to all my friends. Judge a book by its content, not by its author. Do the same for software.
pamcake 9 hours ago [-]
So you enjoyed a book written as a collaborative process between multiple human writers and somehow this is an argument to have less humans involved...?
I would rather frame it as an argument against credentialism.
user-error 2 hours ago [-]
I'm specifically referring to maintainers trying to get new protocols (like border draw calls) into emulators. As these TUI frameworks grow in popularity itincreases pressure on emulator maintainers to support their proposed spec. There's some TUIs I like myself but these generally respect and try to work around the limitations of the terminal. When emulators start shipping with boatloads of TUI-enabling functionality they stop being emulators and start being app frameworks (arguably hard to decide where to draw the line, and everyone will draw it somewhere differently. I draw it in its own cell)
joshka 2 hours ago [-]
I agree. We should definitely never do anything new. Just stop right here. ;)
nottorp 20 hours ago [-]
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.
Timon3 17 hours ago [-]
I don't really see how these terminal borders would make any of these issues worse? You can build a wasteful 144Hz TUI using only dots and spaces. There's a tiny bit of overhead for the extra commands, but everything else seems to be an implementation detail, no?
matheusmoreira 1 days ago [-]
As awesome as this is, but I can't shake the feeling terminals are becoming lightweight browsers...
joshka 1 days ago [-]
What I'd really love to see instead of all of this is an OS that has composable areas that can interact and have event loops of their own. E.g. ditch the app boundary and compose. We're getting there sorta with AI Canvas type things (e.g. github copilot app, some of the stuff in chatgpt visualizations), but all of this sort of work tends to devolve to browser type things instead of simpler components. This is mostly unrelated to the terminal side of things though from my perspective on this. But it's a fun thought experiment.
quadhome 21 hours ago [-]
That was X11.
hobo123 20 hours ago [-]
Exactly. Any GUI element is a "window" and composed of other sub-areas, also windows. You could create windows in the "root window", then the WM would manage then and draw window decorations, but in theory you could also just render a window in a certain area within another window (e.g. a full application, or even just a single view or editor of an application).
I'm not too familiar with higher level frameworks like Qt or gtk, but I suspect since they just draw the whole thing, that they only use single X windows and don't compose them, so you wouldn't be able to render a subview of them inside a different context.
cowlevel 17 hours ago [-]
It's actually unusual for X11 apps to create a window per widget as it comes with a bunch of overhead. Only very old ones do that. However, it does work - windows can be used as widgets and they can cross-embed from other processes. This is very cool but rarely used. It allows you to run a casually sandboxed subprocess with GUI I/O.
They can also just draw on each other's windows and get input events on each other's windows. The connection between a window and its creator process is very weak: the window is automatically destroyed when the creator disconnects. And that's all. You can even turn that off, too. For every request that includes a window (or other resource) ID, nothing says that it has to be your window.
matheusmoreira 10 hours ago [-]
Seems X11 had a lot of potential... Why did it all go to waste? In the end the client side model won. Hardware acceleration?
cowlevel 9 hours ago [-]
Hardware acceleration plus the fact that starting over (to abandon xorg) meant starting over, and features didn't get in by default.
cowlevel 7 hours ago [-]
Plus the fact that apps these days are all doing their own rendering anyway. Factually, they are rarely using X11 server rendering. If they're using any major framework they aren't and the browsers aren't either. Almost all apps are doing something like OpenGL and pushing framebuffers to the display server. That's already happening in X11 so that's what Wayland replicated.
Doing it within your office suite is the easy part. Independent apps make it nigh impossible.
svachalek 23 hours ago [-]
Isn't that Microsoft OLE?
cowlevel 17 hours ago [-]
It is! OLE has to be one of my favourite abandoned technologies.
It does require a lot of deep coupling which is probably why it was abandoned, but also why it worked so well. You had things like passing menu subtree handles back and forth, so the host app and the embedded app could merge together their menus. This only worked because everyone on Windows was using the same menu subsystem, until Office 2007.
joshka 21 hours ago [-]
Similar yes
cowlevel 17 hours ago [-]
X11 supports this.
tliltocatl 16 hours ago [-]
What's wrong with that? I mean, as awesome as plain VT-100 is, we need some way to have a richer text-oriented UI that is still lighter than Chromium.
matheusmoreira 10 hours ago [-]
Complexity. The more capabilities terminals have, the more complex they are, the more difficult they are to implement, the more attack surface area...
I virtualize AI models since I started using them, but they all communicate with me via the terminal emulator. Who knows what sort of exploits are hiding in these things? They could reach my host through them.
montroser 1 days ago [-]
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.
wpm 21 hours ago [-]
My thoughts exactly. Borders costing a cell means you are forced to be frugal with them, lest you run out of space or have to do ugly and clumsy "pwease make ur window biggr :3" messages
One of the top 5 "smells" of LLM generated websites that I can't stand is everything has to have its own round-rect. Everything in a box. Every button, label, header, subheader, so much fucking noise everywhere. You shouldn't need that many.
Another, of course, is the phrase "The wire format", included in this post. Oh yeah, its the format on the wire? What wire? The wire between my psuedo terminal and my kernel? What garbage. Cool exploration but, come on: "The common path is a pen, held in the cursor like the current background color. Set it, print some text, and the printed cells get the borders:" shit is not OK to post
captainmuon 13 hours ago [-]
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?)
nixpulvis 1 days ago [-]
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.
joshka 1 days ago [-]
The ratatui change was a pure PoC, isolated branch, my own fork, not the ratatui repo even. This would likely never ship as a default approach as it would be way too breaking. I haven't really spent any time on making it hook into the current block border approaches - it's just at the cell level where this is opted in. That will never merge without much much more though into things.
I used ratatui there mostly so that I could prove that it would work in real looking apps that do panels and similar stuff that benefits from borders.
But yeah, compat is key. It would probably go out to ghostty, rio, kitty pretty easily, terminal.app never, other terminals much slower. IDK about the windows / linux side of things.
nixpulvis 1 days ago [-]
I used to be an active maintainer for Alacritty. I expect uphill resistance to this there, though that won't surprise anyone who uses it.
BTW, love ratatui. I've been building ratmark lately, for markdown rendering. But I really need link support ;)
joshka 1 days ago [-]
It should be coming soon. :) Sometime in the next couple of weeks is the vague handwavy forecast.
inguz 8 hours ago [-]
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.
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?
(The usual disclaimers apply: all of the actual code is AI written)
joshka 4 hours ago [-]
Good find. Thanks for the validation. I expect there's ways to make this reasonably performant on most terminals. It's the adoption part that really matters on this. I mentioned elsewhere that doing ghostty, kitty, rio, would be fairly simple. But that's like 5% of the terminal user's market. xtermjs for vscode would be meaningful. But Terminal.app and Windows terminal would be a much tougher hill to climb.
weinzierl 14 hours ago [-]
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.
Neat - yeah, I recall futzing around with character rom stuff in the early 8086 days too, being able to peek and poke character drawing locations to do custom cell graphics was pretty magical. The problem with it for this sort of thing is that fonts are more than raster things these days, you don't have an 8x8 grid to play with. But that said, take a look at what raph is doing with rio. https://x.com/raphamorims/status/2120887890129388001
weinzierl 4 hours ago [-]
Nice, was new to me.
yonatan8070 19 hours ago [-]
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.
Timon3 17 hours ago [-]
That would be awesome! IIRC zellij supports this, but that only works as long as it intercepts all selection inputs. Having a more universal standard that terminal emulators can support would be great.
cobychapple 1 days ago [-]
Would be cool to get borders and lines out of copy/paste
hnlmorg 1 days ago [-]
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.
joshka 1 days ago [-]
Tmux drops DCS that it doesn't know like this. That aside, this is extra state per cell that needs to be tracked, handled, understood from a rendering perspective etc. It can work, but would require maybe a thousand lines of code or so to support storing and handling state, redraw etc. and all the various edge cases.
hnlmorg 20 hours ago [-]
Really? That surprises me. Not saying it’s untrue, just that I’m surprised. I’ve found tmux doesn’t drop CSI, OSC nor APC.
I wouldn’t recommend APC because Apple Terminal doesn’t follow spec with APC parsing (one of the reasons I switched some of my custom sequences from APC to OSC).
Regarding the extra state to be tracked, tmux wouldn’t handle that cell state. That would be down to the terminal emulator.
Since these are cell properties, it does feel like CSI would be the right place (like Kittys undercurl).
CGamesPlay 1 days ago [-]
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.
joshka 1 days ago [-]
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.
andix 13 hours ago [-]
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.
teo_zero 13 hours ago [-]
And while we're at it, a better TERM variable, not the "user-agent header" of terminals that it is now.
To be more precise, TERM contains a single name, a key to index terminfo, a database of all known terminals and their capabilities. It assumes that such database is up to date and that every app has access to it, which is not always true, especially on non-unix platforms.
However, apps have begun using the name "as is", comparing it against known strings, e.g. "xterm", which led many terminals to advertise themselves as xterm just to ensure compatibility with existing apps.
A truly meaningful substitute for TERM would be a "semantic TERM", a variable that, setting apart the name of the terminal, focuses on the capabilities it offers. Not the complete set of properties listed in terminfo (we can give most of them for granted, today), but just the subset that differentiates modern terminals, like colors, kitty's protocol, OSC133, and a few others.
nkmnz 18 hours ago [-]
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?
korm 17 hours ago [-]
Windows Terminal allows moving the cursor by clicking. It's such a good terminal emulator that it's the thing I miss the most when I'm on Linux.
> Windows Terminal [...] It's such a good terminal emulator
I find it horrible. Slow, colors are inconsistent, resizes are not always propagated to apps...
What terminal do you use on Linux that makes you miss WT?
cowlevel 17 hours ago [-]
Because a terminal emulator is emulating 1970s technology and the mouse hadn't been invented yet. We do have a way for apps to accept mouse input, believe it or not, but it's usually done by avoiding the 1970s emulation layer. As a bonus, you get full control over your screen pixels too!
nkmnz 17 hours ago [-]
This is true for all the other magic things I'm always reading about with the newest, hottest, terminal emulator tech XYZ, as in this article. People do amazing stuff with those tools. I'd already be very happy if the current line I'm writing in would have the convenience of a 1993 Mosaic input-element.
Also, selecting and replacing could be done without a a mouse. Quite often I want to select, copy, replace, paste somewhere else. Not possible without a mouse.
ianberdin 16 hours ago [-]
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.
Evidlo 15 hours ago [-]
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?
pkulak 1 days ago [-]
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.
wg0 16 hours ago [-]
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?
jiehong 17 hours ago [-]
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.
nmstoker 1 days ago [-]
Love this. And the people who like more space can opt for that (this doesn't look things in).
tripa 19 hours ago [-]
Before I clicked I interpreted the title as airport terminals whose border controls don't require a burner phone.
dead_hn_theory 1 days ago [-]
There's a nice thread about this on lobsters, but the author is getting piled on.
joshka 1 days ago [-]
I upvote naysayers comments there as I don't think votes should be used to indicate (dis)agreement at least not without commenting why, more an indication that this is a useful thing to discuss. So if you see my comments not getting votes while every other one has a bump, that's my vote on them :)
It's kind of funny, I posted this here and there at similar times. Expected to be spam flagged there due to the anti-AI brigade, but my submission here was the one that actually got hit (likely because I disclosed AI use in the post body is my guess).
hobo123 20 hours ago [-]
Same here. Alas, it's the zeitgeist that everything runs along tribal or political lines these days, but it doesn't have to be that way.
I like seeing different points of view, and maybe controversial topics should be discussed () more than others, not less.
and discussed means fact-based, civil discourse, not piling 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.
xixixao 20 hours ago [-]
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.
codesnik 15 hours ago [-]
neat!
but, so, for borders around button text, rightmost border terminal sequence would have to be inserted before the last char, right?
I like it. As an analogy, borders are important features of spreadsheet tools as well.
vessenes 15 hours ago [-]
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.
ganelonhb 1 days ago [-]
This is gorgeous and I need it in trunk for both kitty and ghostty
eviks 1 days ago [-]
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?
joshka 1 days ago [-]
Sure - I use GUIs most of the time despite maintaining Ratatui. I much prefer them for coding agents as the amount of interactions and various things I want out of the interface are not handled by TUI well. GUIs are a vastly superior interface (I worked on the Codex TUI at OpenAI btw).
neomantra 21 hours ago [-]
This funny to read! I drive Codex TUI daily. In the past, I paired it with VSCode for better code navigation and file reading; seems similar to what you are saying or do you also mean Source Level Debuggers, etc.? But, I eventually worked on Kitty terminal typesetting instead and now reading the files with my gloss tool [1]; combined with Rex blocks it's really nice, easier on my eyes.
Thanks for Ratatui, which certainly has a top tier name, and also has had tons of great software written with it! I've been inspired by much of that ecosystem, especially the charting libs. The weird GUI stuff I'm doing with Kitty+Bubbletea, can certainly be done on Ratatui, in the spirit of Makepad. IMO, Golang needs this more than Rust.
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.
lilbigdoot 1 days ago [-]
I like it
krautburglar 1 days ago [-]
Why do you people have to ruin terminals? If you wanted a web browser, we already have those, and they already have borders.
hobo123 20 hours ago [-]
I think that's a fair question. It seems that people want more keyboard navigation and (sometimes) monospace UIs, but that should be perfectly feasible in a web UI.
Myrmornis 7 hours ago [-]
OK so how would this work? Say I'm doing filesystem operations, using git etc, and I want to do something related to that with an interactive UI. How do I "get from" the terminal into a web UI? Or am I doing filesystem operations and using git etc in the web UI from the start?
krautburglar 7 hours ago [-]
Look at the DEC SGR codes as a markup. Most CLI progs automatically include/exclude them depending on whether the output is a tty or not. Many also have flags to force enable/disable them. It is entirely do-able to add an HTML output mode for pretty-print, auto enable/disable it depending on $TERM, and use some browser thing as your terminal. That way, webshitters can get all of the webshit they want, and my VT220 stuff keeps working.
krautburglar 13 hours ago [-]
Everybody has their own personal itch. It will not stop -- even after they get to stylesheets. Some people may not remember this, but there was a time when browsers were also simple.
I believe the relevant saying here is, "normies ruin everything". Now that LLMs have allowed them to breach the command line, "Chrome, here we come!"
Son of a motherfucking bitch.
kevin_thibedeau 1 days ago [-]
How much RAM does this use?
joshka 1 days ago [-]
Nothing really - Ghostty has a bit of padding that's unused per cell - 16 bits. The implementation stores an ID into a lookup table with border combinations. If all of those were used and never cleaned up, 65535 at around 100 for each combination used, order of magnitude 25MB absolute worst case assuming no real optimization in place for this.
0c3ca83 1 days ago [-]
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?
kodoman 1 days ago [-]
I think the other side of things is why have the graphic program run over ssh, just have raw text cli tools to manipulate what ever then have a program driving it. This for me is where emacs excels and some programs already fit well with this model and the fantastic (albeit hacky) tramp.
tcfhgj 1 days ago [-]
No, i really don't want to have electron level bloat as a terminal
rvz 1 days ago [-]
Honestly why? It is not designed at all for that.
In fact it just makes it less secure.
echoangle 1 days ago [-]
You mean serving html over SSH?
It can already port forward so you can basically already do this, I don’t think that’s insecure per se.
zokier 1 days ago [-]
Doing it through port forwarding is kinda bad though because generally access to network ports is not very well access controlled. Doing it through unix sockets (like x) would be much better but annoyingly browsers do not support http over uds
Ssh lets you forward arbitrary ports, and forward X11 directly. Why is HTML more of a problem?
drdaeman 1 days ago [-]
> 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 1 days ago [-]
While we're figuring it out let's call this hypothetical protocol X.
em-bee 1 days ago [-]
the thing with X and wayland etc is, that they are low level. which is fine if you want full control over the presentation. what HTML was trying to do is to go higher level, send over some data and let the browser figure out how to present it. but it went wrong and people are abusing it as a low level presentation interface like X or wayland.
what we are missing is a really high level protocol/system that takes really high level data and figures out the presentation on its own.
take a list of files for example. you can run ls -l in a terminal and it will attempt a crude text based formatting of the output. or you can run a full gui filemanager.
what if there was a command that would produce ls output as a table data structure, run in a sort of terminal that knows how to format a table nicely without the ls command having to include any formatting instructions? this terminal would have support for all sorts of data types and structures to display all of them nicely.
skydhash 1 days ago [-]
> Take a list of files for example. you can run ls -l in a terminal and it will attempt a crude text based formatting of the output. or you can run a full gui filemanager.
ls's output (and a few other programs') are human facing. They're not meant to be machine readable.
> what if there was a command that would produce ls output as a table data structure, run in a sort of terminal that knows how to format a table nicely without the ls command having to include any formatting instructions? this terminal would have support for all sorts of data types and structures to display all of them nicely.
Because that's just complexity for its own sake. What's simpler is to just create a shell alias for a particular view you want. The shell is for interactive usage, with some capabilities for automation. If something better is needed, you write a real program for it.
em-bee 11 hours ago [-]
ls's output (and a few other programs') are human facing. They're not meant to be machine readable.
many shell scripts are using ls as input. maybe a better example is ps. that's even more common i would guess.
the goal that i am proposing is to separate output and presentation. that is way more powerful. make commands with machine readable output, and add a presentation layer that converts that to something human readable.
for backwards compatibility you could call that command "show" so you would have
ps | grep | sort | show
where every step except the output at the end deals with machine readable data.
future terminals could skip the "show" step and read and format the machine output directly with all the power that this gets you such as the ability to reorder or resize columns, change the sorting order, etc, for the ls case like a gui filemanager, but commandline driven and able to handle any output of any command.
create a shell alias for a particular view you want
which shell alias lets me easily reorder or remove columns from ls or ps output? or change the sorting order with a single key press (like top does for example)
top/htop is a good example btw: it's an interactive interface for the output of ps.
imagine you could do the same thing by just running ps or ps | show? generic enough that it works for most commands producing structured data?
arboles 1 days ago [-]
> what if there was a command that would produce ls output as a table data structure, run in a sort of terminal that knows how to format a table nicely without the ls command having to include any formatting instructions? this terminal would have support for all sorts of data types and structures to display all of them nicely.
So, powershell? For some reason only IT jockeys on Microsoft's death grip remember and use its full capability after learning it.
drdexebtjl 1 days ago [-]
There are many problems with powershell, but to me the absolute worst, won't even touch it with a 10-feet pole, is UTF-16.
ncruces 1 days ago [-]
We could even use `ssh -X` to send it over SSH if that flag is otherwise unused.
cluckindan 1 days ago [-]
I think it would make sense if it had a client-server architecture.
arboles 1 days ago [-]
And for the ecosystem's sake, punish (harshly) GUI toolkit developers that use bitmap rendering (GTK4 and Qt Quick applications are slow on ssh -X).
PeeMcGee 1 days ago [-]
> In this role, HTML is a pile of hacks upon hacks that was not originally intended for UIs.
I get where you're going and am genuinely curious, what does a "better" system designed to do what HTML/JS have become actually look like? (or what would one look like?)
There has to be markup of some sort, and there has to be scriptable interactions of some sort, right? If not, how else would it work?
drdaeman 20 hours ago [-]
Well, yea, that was a remark about HTML's legacy. In pre-AI era, I preferred QML or GtkBuilder (when viable, of course) to HTML any time. Nowadays, to be honest, I don't know.
That said, yes: NeWS, XForms, rio, and many others have tried with arguably cleaner designs. Not without their own issues, but in comparison to HTML, driving GUIs was a design goal from day zero (not a direction shift), and they're a lot smaller and simpler (which has its pros and cons).
em-bee 1 days ago [-]
plan 9?
orbital-decay 1 days ago [-]
UI in a browser is a massive hack in itself, a clean design would be better. For example a compact semantic remote access protocol to use with UIs, something like SPICE but better optimized for networks, fully presentation-independent, and less janky. This would let everyone use a GUI framework of their choice with an adapter. But people building terminal GUIs are culturally not ready for this, they'd rather continue reinventing the wheel and piling up hacks in terminals. I wonder when they realize that proportional fonts are more readable when vertical alignment is handled separately, and introduce terminals with variable-width fonts. And the presentation layer (I suggest calling it CSS).
charles_f 1 days ago [-]
> If that bothers you, feel free to close the tab.
I probably missed on something, but I stopped there
oasisbob 24 hours ago [-]
Normally I would too, but after reading the article, I really don't have any complaints. Disclosure is appreciated too.
Whatever the author is doing works reasonably well to be readable and inoffensive.
joshka 4 hours ago [-]
I definitely missed a bunch of AI generated prose in there. But I did my best to read most of it and pull out anything egregious that felt off. If you throw it into any AI detection software it will probably come up as 100% AI written. I write fairly verbosely regardless of AI.
octoberfranklin 1 days ago [-]
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.
movingimage 1 days ago [-]
“….that don’t cost a cell.” How much do I hate AI hustle bro passive riddle writing.
TacticalCoder 1 days ago [-]
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).
joshka 1 days ago [-]
This was intentional to highlight the borders more obviously.
The side gaps were for for making it feel balanced in the screenshots and visualizations to be able to show where the borders line up with cells easily etc. It wouldn't be what I'd use in a real app.
One thing to note though is that some things which are "wrong" can be aesthetically pleasing to look at and may be the actual best UX in certain situations. There's a lot of new design principle work (especially in macOS / iOS) that is about things going past the edge, or being overlaid with floating things. Some of this is "wrong" some of it is wrong, and some of it sitting in in the useless gap beteen the two. ;)
db48x 1 days ago [-]
Man, I’d really like a monitor with no edges. One that just keeps going and going, past my window and the tree outside until it’s completely out of sight. 100% useful area.
favori995749721 1 days ago [-]
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?
yoy0721 17 hours ago [-]
[flagged]
dharmasthan 1 days ago [-]
[flagged]
kenzo_cavanaugh 1 days ago [-]
[flagged]
18 hours ago [-]
milosz0010 20 hours ago [-]
[flagged]
movingimage 1 days ago [-]
“That don’t cost a cell.” Can’t stand AI bro speak.
graypegg 12 hours ago [-]
> The common path is a pen, held in the cursor like the current background color. Set it, print some text, and the printed cells get the borders
It's wild how LLM written text is a contaminant detectable in the parts-per-million range.
Saying that, the idea is actually good, and I at least appreciate that the author warns ya up front.
joshka 4 hours ago [-]
Yeah, that's pretty janky - missed it in editing.
I've made the point elsewhere that the actual spec is the the bit I care least about on this. There's multiple ways that are valid for actually doing it - DCS, ASC, SGR, CSI, Overtype, etc. - the point of it is to argue for the outcome borders that are are between the cells not using one.
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've really enjoyed using it on paper: https://hughpyle.com/ASR33/
Ages ago I had found a software that would convert an image to ascii-art, and then used another tool called posteriza to split the large image into several A4s, which I then taped together and hung on my wall. Would love to do something similar but with better tools.
Damn, that's one from back in the day.
Pretty unlikely they'd be into adding a new ZWJ pattern for bordering characters since it's awful given unicode's main goal is interoperability. If you copy text out of your terminal, those characters come with it and probably won't render correctly in non-terminal applications (which don't have monospaced text cells), so you'll just see the ? missing character symbol between every letter. (Possibly overstruck onto the previous character depending on handling for the ZWJ.)
I guess the other way to look at this would be "should the background colour be a unicode ZWJ pattern?"... probably not. The border (and colour) is a property of the terminal cell rather than the actual characters IMO. It's not like `X + ZWJ + LEFT-BORDER` has any unique encoded meaning. Cell attributes like the article is talking about IS the less archaic way of doing this. ZWJ patterns are a lot more archaic and cause a lot more issues. Overstrike is fine, if it's being down with cell attributes (meaning, moving the cursor overtop of a cell, and stamping a new character on it instead of replacing it. Exactly how mintty does it.)
This was only true before emojis. Unicode introduced specific code points purely to alter visual display, such as skin-tone modifiers, etc. Now that the mission was already diluted for emo-fluff, you might as well add actually useful fluff.
The ones they DO let through, must have some sort of useful distinction in meaning to be given a code point(s). It can't just be useful as a little image of a thing. It has to provide some sort of linguistic concept that extends the emoji... language? https://unicode.org/emoji/proposals.html#factors_inclusion
The skintone modifiers are meaningful because it can look more like someone you're talking about. "S with a left border" isn't disambiguating any sort of meaning from "S with a bottom and right border".
It solves the z-index problem neatly for an individual cell as you just render in order (first underneath, second over the top). But it doesn't solve the order for adjacent cells - borders that lie between cells. At least not easily. Not an insurmountable problem.
Some perspective if you're unaware. Fonts have the unicode line drawing characters, but fonts don't align super well and so a good terminal will draw those characters with line drawing algorithms instead of as a font. I've got a WIP PR that I need to land in VSCode's that pulls in xtermjs and ghostty's line drawing stuff so that it fixes up all the existing gaps on that as an example of this problem.
Plus, just complexity wise, I'd much rather just have a DCS sequence to draw vector lines like the article's suggestion than first send all the borders then home the cursor, send the overstrike sequence, send all the content, send the overwrite sequence. That has so many more places where a session gets trashed by accidentally sending the wrong control character.
But I’m not trying to argue for nor against either solution.
This isn’t an issue if you want square borders. But the screenshots in the article showed fancy rounded corners.
The syntax is:
CSI 53 m SGR 53 — Overlined CSI 55 m SGR 55 — Not overlined
which is much more different than mitty's Control Sequence, but supports much more emulators
You might think it's a bit complicated, but I counter: so are terminal escape codes.
If you want those things then overstrike is insufficient.
Edit: HN stripped the characters in question from my comment
I've written about it before, but in brief the mountain of standards is worth ripping out wholesale and doing write as a semantic protocol. It's needed to solve several things that work really poorly in terminals because their unit of compatibility is cells rather than a higher primitive. It's hard to bake something on top that works well.
The need is most strong in Accessibility, Text wrapping, Scrollback handling (i.e. making the scrollback editable and not dead text), and various other bits that make writing highly functional TUIs. Coding agents tend to find all those edge cases.
This often gets push back that it's easy, to which I can point nay sayers at the various many months long issues on things in Codex, Gemini, Claude etc. on flickering, scrolling, key handline, IME, ... doing anything moderately complex involves modeling a terminal in a terminal app effectively.
Ghostty and Rex sort of do the opposite bit. If you think of it like a stack, they write a new layer underneath that transports the cells on a better multiplexer layer 0. I think a new semantic layer 2 is an approach that would be neat to work with.
Fundamentally this is the wrong abstraction and it is painful to develop modern terminal features on top of it.
We need a terminal compositor protocol. We need to leave the pty behind and replace it with a unix socket. What other compositing protocols exist in the modern tech stack that we could extend?
Anyone can feel free to reach out to me if they want to chat about it: https://bower.sh
I think there was some discussion about this last time I mentioned the idea on hn a few weeks / months back. Trawl my history to find it pehaps.
- When you write cells, you don't have an area of the screen that you can treat as the current area, which makes screen readers have to treat the screen as characters and recompose those back into words to read. You lose any rectangular area concept and treat lines in the terminal as lines that the screen reader reads. Semantically you throw away all the layout information by writing to the terminal.
- When you write stuff to the screen and then write enough lines to the screen to push lines into the scrollback, you lose the ability to change those lines in future. You can move the cursor anywhere in the screen viewport, but not anywhere outside of it. Scrollback is dead text once written there. This is fine for most apps that need append logic, but less so where you have reasons to treat the terminal as a space where you update it or gain access to things like expanding info. e.g. pick up claude code or codex and think about how you collapse a diff or command output to headers and then expand it, in the viewport, not a problem, in the scrollback it's dead text written once.
- There's a mismatch in the way that wrapping works when applied to the screen. If you're wrapping text at the screen boundary, and letting the terminal select across lines, it hits the edge of the terminal, and wraps to the next line. There's no concept of the edge of a block, because cells are the base level primitive. This affects selecting text, copying it, etc.
- Resizing terminals after stuff has written requires repainting the existing screen and then taking care about what was written to the scrollback history. E.g. if you have 200x50 and resize to 200x49, the top line just entered the scrollback and is now part of the history that you can't edit. Unless you clear the entire scrollback and repaint. Again similar problem and reasons. Resizing to 199x50 is worse, because you lose a character on each line, and push stuff into scrollback. And also the opposite 200x51, you just pulled a line from the scrollback now, so now you have to consider what to write back to that line later - what was dead is now alive again. These problems make writing terminal coding agents that rely on having interactive parts of the screen and history parts of the screen tough.
- Scrolling in general. If you look at how each terminal scrolls, and how many lines it maps to each mouse scroll wheel action, it differs per terminal, and it differs based on mouse / trackpad use as well. The events you get are not standardized in count, frequency, acceleration, ... This makes doing anything related to scrolling when you own the entire screen and scroll state a pain as you're trying to emulate the terminal's native feel and that differs a bunch. So there's a strong missing abstraction over scroll state things instead of just plain mouse events. Having a terminal and app level collaborate to tell where the scroll is up to is the approach that seems to be necessary here.
A lot of this comes from the fact that terminals are a mix of standards tracing back many years, stacked on top of each other, implemented poorly or not at all, ECMA, VT, DEC, iTerm, Kitty, OSC, ASC, DCS, SGR, ... and they all deal in cells being the basic primitive rather than the higher level semantic thing you need to do a TUI that is region aware. That's a impedance mismatch that is hard to bridge without a new standard that just sidesteps it completely.
If you look at the history of Codex / Gemini / Claude Code, they've each run into this problem a bunch over time and solved various bits of it / ignored other bits of it.
It's narrower than replacing the cell grid. A program asks for a view the way vim takes the alternate screen. If the terminal answers, the program hands it the view's files once, and from then on the two exchange six small messages inside the normal byte stream (APC frames, the same trick kitty graphics uses). No port and no extra connection, so it works over plain ssh to a box with no GPU. When the program exits you get your terminal back, and in a terminal that doesn't answer the program can fall back to plain text.
A view is either a Lua script the terminal draws itself, in its own font and theme, or a sandboxed web page. The second one is exactly the "terminals are becoming browsers" worry from upthread, and I don't think that worry is wrong, which is why the native kind exists. Going through tmux is a non-goal: a multiplexer that doesn't pass the stream through untouched just means the program sees no host and falls back.
The only host so far is bateri, the macOS terminal I'm building, and the spec is an early Apache-2.0 draft: https://github.com/bateri/pencere/blob/main/spec/draft/pence...
Do they? Last time I checked you still couldn't select text via the keyboard in the Claude Code TUI.
I can only speak for myself but I use the CLI and TUIs specifically because of the limitations those modalities impose on software that uses them as the primary method for interfacing with the end user. If you want a full featured UI and all that comes with it why not just use QT or GTK or modern HTML or etc?
I think the only "improvements" I'd like to see are thing such as metadata regarding what the different streams are for, an official way to communicate using structured data as opposed to raw bytes, that sort of thing. Spiritually in the same ballpark as the difference between HTML before and after CSS.
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.
The developer seems to have used AI heavily in the elisp code and it works very well.
> I'm surprised i've not seen more of this in the past to be honest.
This is what emacs is. It's a text buffer, but text can have properties like how to render, and custom values. then a bunch of commands to manipulate the buffer and it's contents.
I'll look into that, thanks!
Terminals work so well because there's a huge frictional cost to adding to the protocol. That's what keeps the protocol simple, which is what keeps multiple implementations feasible. Unlike the web, where unless you have GoogleBux you can't afford to implement it properly.
I also don't like the fact that each TUI application (btop, for instance) comes with its own color palette. So, a friend of mine developed a terminal (https://bateri.dev, macOS only for now, but the plan is to port it to Linux later) and yet another protocol where terminal SPAs can communicate over standard SSH (inspired by X over SSH, but we didn't like its drawbacks). The SPA itself is a set of Lua scripts that runs in a sandbox inside the terminal. The application on the host that communicates with the SPA can be implemented in any language (preferably Lua to keep it simple). With this approach, all SPAs (plugins) adhere to the user's color palette preferences. (There are more details that can share if you are interested.)
So far, to stress test it and help with devex, he has built a text editor (https://github.com/bateri/textpen) and a Docker/task monitor (https://github.com/bateri/dockerpen). I am also working on a plan document viewer that works within the terminal. We'd love some feedback if you are interested.
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.
If we must embed 2D interfaces in terminals, I feel like we'd be better off putting in iframes or canvases that occupy a dedicated rectangle of cells.
You just run `mycommand connect host` and it will connect via SSH, start a Wayland server with X support, set up the appropriate environment variables, and also automatically reconnect, so you only have to do this once.
After that you can just run GUI commands via SSH and appear locally like you always wished they would. It uses a VNC-like image data protocol so the client works on any OS. And windows are seamless - no windows within windows nonsense. I haven't put much effort into the video protocol tbh but it's already better than Xpra and very usable with 100ms latency (London to NY) so that's good enough for me.
I'll try to open source it.
I think a better solution would be if SSH itself supported some GUI channel, but the only thing is the Kitty graphics protocol which kind of sucks tbh. I did try writing some tools using that for the GUI a while back but it's awkward because you have to use PNG, you're still stuck with the character grid for text, etc.
I'm running an old Qt X11 app with a modern retina MacBook with multiple different density screens and it works fine. There were some minor issues with that to start with but I pretty much just said "this happens, please fix it" and Claude figured it out without even having access to a Mac, which is impressive.
Honestly the thing that was hardest was keyboard layout. That kind of stuff never worked well for me in any remote desktop app, and now I can see why! You might never notice if you only use the US layout tbf. It works pretty well now though - I got it to query your local layout and the dynamically build an X keyboard layout and send it to the server.
I've run it with up to about 4 large windows and it seems to work fine. It doesn't send anything when nothing is changing so lots of windows won't matter unless they're playing videos or whatever - it's more designed for old Windows/Qt/Gtk style apps. I suspect you could do better with a traditional video codec but unfortunately the server I use has no GPU so that wasn't really an option.
However, most X11 apps will have utterly abysmal performance on WAN SSH connections. Ancient apps will be slow because they block waiting for every response (this is unavoidable in Xlib) and less than ancient apps will be slow because they send full pixel data. It is possible to write a reasonably performant remote X11 app (using XCB instead of Xlib and always being aware of latency), but there are very few such apps. This is why Wayland dropped the requirement.
There used to be one. It was called X forwarding. You'd run ash -X or ssh -Y and it magically worked.
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.
2. I agree if you refer to TUIs that try to emulate/substitute complex GUIs, with sub-panes, dialogs, graphics, etc. I happen to love TUIs for simple text-only visualizations, though. They are usually quicker than GUIs and consistent among various OS, desktop...
But it IS relevant how something was made! It tells us how much of the detail that's presented in code & blogpost is the authors intent, and how much of it is "filler". It tells us whether the author can answer detailed question as to why they chose a specific implementation, or novel technique, or not.
It tells us whether the author wants us to read every syllable, or whether readers are expected to let their own summarize the article for them instead (as would be the case here).
It's never worth it to spend more effort reading something than the author spent writing it. The important part is the human intent, not the filler surrounding it!
I would rather frame it as an argument against credentialism.
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.
I'm not too familiar with higher level frameworks like Qt or gtk, but I suspect since they just draw the whole thing, that they only use single X windows and don't compose them, so you wouldn't be able to render a subview of them inside a different context.
They can also just draw on each other's windows and get input events on each other's windows. The connection between a window and its creator process is very weak: the window is automatically destroyed when the creator disconnects. And that's all. You can even turn that off, too. For every request that includes a window (or other resource) ID, nothing says that it has to be your window.
https://en.wikipedia.org/wiki/Framework_(office_suite)
It does require a lot of deep coupling which is probably why it was abandoned, but also why it worked so well. You had things like passing menu subtree handles back and forth, so the host app and the embedded app could merge together their menus. This only worked because everyone on Windows was using the same menu subsystem, until Office 2007.
I virtualize AI models since I started using them, but they all communicate with me via the terminal emulator. Who knows what sort of exploits are hiding in these things? They could reach my host through them.
One of the top 5 "smells" of LLM generated websites that I can't stand is everything has to have its own round-rect. Everything in a box. Every button, label, header, subheader, so much fucking noise everywhere. You shouldn't need that many.
Another, of course, is the phrase "The wire format", included in this post. Oh yeah, its the format on the wire? What wire? The wire between my psuedo terminal and my kernel? What garbage. Cool exploration but, come on: "The common path is a pen, held in the cursor like the current background color. Set it, print some text, and the printed cells get the borders:" shit is not OK to post
I used ratatui there mostly so that I could prove that it would work in real looking apps that do panels and similar stuff that benefits from borders.
But yeah, compat is key. It would probably go out to ghostty, rio, kitty pretty easily, terminal.app never, other terminals much slower. IDK about the windows / linux side of things.
BTW, love ratatui. I've been building ratmark lately, for markdown rendering. But I really need link support ;)
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
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)
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
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.
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 wouldn’t recommend APC because Apple Terminal doesn’t follow spec with APC parsing (one of the reasons I switched some of my custom sequences from APC to OSC).
Regarding the extra state to be tracked, tmux wouldn’t handle that cell state. That would be down to the terminal emulator.
Since these are cell properties, it does feel like CSI would be the right place (like Kittys undercurl).
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.
Instead of adding extension over extension on top of some old protocol. And using a lot of hacks to get stuff done.
To be more precise, TERM contains a single name, a key to index terminfo, a database of all known terminals and their capabilities. It assumes that such database is up to date and that every app has access to it, which is not always true, especially on non-unix platforms.
However, apps have begun using the name "as is", comparing it against known strings, e.g. "xterm", which led many terminals to advertise themselves as xterm just to ensure compatibility with existing apps.
A truly meaningful substitute for TERM would be a "semantic TERM", a variable that, setting apart the name of the terminal, focuses on the capabilities it offers. Not the complete set of properties listed in terminfo (we can give most of them for granted, today), but just the subset that differentiates modern terminals, like colors, kitty's protocol, OSC133, and a few others.
https://github.com/microsoft/terminal
I find it horrible. Slow, colors are inconsistent, resizes are not always propagated to apps...
What terminal do you use on Linux that makes you miss WT?
Also, selecting and replacing could be done without a a mouse. Quite often I want to select, copy, replace, paste somewhere else. Not possible without a mouse.
Is it because it looks visually crowded?
The charm of the terminal is that you can do whatever you want, as long as it fits in one cell.
It reminds me of video games overlays / layers (like the gameboy window layer) used to display HUDs.
It's kind of funny, I posted this here and there at similar times. Expected to be spam flagged there due to the anti-AI brigade, but my submission here was the one that actually got hit (likely because I disclosed AI use in the post body is my guess).
I like seeing different points of view, and maybe controversial topics should be discussed () more than others, not less.
and discussed means fact-based, civil discourse, not piling on[background color, top, left, bottom]B[top, bottom only]UTTO[top, bottom, right]N[reset]
Thanks for Ratatui, which certainly has a top tier name, and also has had tons of great software written with it! I've been inspired by much of that ecosystem, especially the charting libs. The weird GUI stuff I'm doing with Kitty+Bubbletea, can certainly be done on Ratatui, in the spirit of Makepad. IMO, Golang needs this more than Rust.
[1] Viewing the gloss README in the Gloss web viewer (Golang WASM in a Ghostty frame), press 't' to typeset it. Alpha release quality. https://nimbleterminal.github.io/gloss/app.html?src=https%3A...
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 believe the relevant saying here is, "normies ruin everything". Now that LLMs have allowed them to breach the command line, "Chrome, here we come!"
Son of a motherfucking bitch.
In fact it just makes it less secure.
It can already port forward so you can basically already do this, I don’t think that’s insecure per se.
https://bugzilla.mozilla.org/show_bug.cgi?id=1688774 etc
> 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…
what we are missing is a really high level protocol/system that takes really high level data and figures out the presentation on its own.
take a list of files for example. you can run ls -l in a terminal and it will attempt a crude text based formatting of the output. or you can run a full gui filemanager.
what if there was a command that would produce ls output as a table data structure, run in a sort of terminal that knows how to format a table nicely without the ls command having to include any formatting instructions? this terminal would have support for all sorts of data types and structures to display all of them nicely.
ls's output (and a few other programs') are human facing. They're not meant to be machine readable.
> what if there was a command that would produce ls output as a table data structure, run in a sort of terminal that knows how to format a table nicely without the ls command having to include any formatting instructions? this terminal would have support for all sorts of data types and structures to display all of them nicely.
Because that's just complexity for its own sake. What's simpler is to just create a shell alias for a particular view you want. The shell is for interactive usage, with some capabilities for automation. If something better is needed, you write a real program for it.
many shell scripts are using ls as input. maybe a better example is ps. that's even more common i would guess.
the goal that i am proposing is to separate output and presentation. that is way more powerful. make commands with machine readable output, and add a presentation layer that converts that to something human readable.
for backwards compatibility you could call that command "show" so you would have
where every step except the output at the end deals with machine readable data.future terminals could skip the "show" step and read and format the machine output directly with all the power that this gets you such as the ability to reorder or resize columns, change the sorting order, etc, for the ls case like a gui filemanager, but commandline driven and able to handle any output of any command.
create a shell alias for a particular view you want
which shell alias lets me easily reorder or remove columns from ls or ps output? or change the sorting order with a single key press (like top does for example)
top/htop is a good example btw: it's an interactive interface for the output of ps.
imagine you could do the same thing by just running ps or ps | show? generic enough that it works for most commands producing structured data?
So, powershell? For some reason only IT jockeys on Microsoft's death grip remember and use its full capability after learning it.
I get where you're going and am genuinely curious, what does a "better" system designed to do what HTML/JS have become actually look like? (or what would one look like?) There has to be markup of some sort, and there has to be scriptable interactions of some sort, right? If not, how else would it work?
That said, yes: NeWS, XForms, rio, and many others have tried with arguably cleaner designs. Not without their own issues, but in comparison to HTML, driving GUIs was a design goal from day zero (not a direction shift), and they're a lot smaller and simpler (which has its pros and cons).
I probably missed on something, but I stopped there
Whatever the author is doing works reasonably well to be readable and inoffensive.
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).
The test app has a key to turn that off see https://github.com/joshka/ratatui/blob/joshka/cell-borders/C...
The side gaps were for for making it feel balanced in the screenshots and visualizations to be able to show where the borders line up with cells easily etc. It wouldn't be what I'd use in a real app.
One thing to note though is that some things which are "wrong" can be aesthetically pleasing to look at and may be the actual best UX in certain situations. There's a lot of new design principle work (especially in macOS / iOS) that is about things going past the edge, or being overlaid with floating things. Some of this is "wrong" some of it is wrong, and some of it sitting in in the useless gap beteen the two. ;)
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?
It's wild how LLM written text is a contaminant detectable in the parts-per-million range.
Saying that, the idea is actually good, and I at least appreciate that the author warns ya up front.
I've made the point elsewhere that the actual spec is the the bit I care least about on this. There's multiple ways that are valid for actually doing it - DCS, ASC, SGR, CSI, Overtype, etc. - the point of it is to argue for the outcome borders that are are between the cells not using one.