Ngoni.

Appreciate the follow-up, and no apology needed for building something. The only issue was the characterization of the comparison. I'm sorry it got so much attention! I gave the feedback in exactly the same tone and style I would if someone I worked with professionally (at any level) came to me and showed me the work and made the same claims. I looked at the way you process/drop data in your circbuffer and VT parser and I was suspicious of HOW much you want to sacrifice correctness, so I want to be specific about what "sacrifices correctness" means here, because I think it's more than it sounds. I'm NOT trying to "mog you" or be mean here, I'm just trying to point out some things you might find helpful, and perhaps help you learn something (if you want). - A 120 KB plain text file: 137 of 300 lines never exist (e.g. your dropping data that technically fits in your scrollback), and the first visible row is a mid-line cut-off fragment. - Same file preceded by CSI ?1049h (the alt-screen switch) is dropped, so all 163 surviving rows land on the primary screen and in scrollback. - A cut inside a truecolor SGR prints `;2;226;54;22m` as text. Similarly, a cut inside an OSC 8 prints the URI as text. The threshold for this isn't a massive firehose. It's any output over 64 KiB between frames: a `git diff`, a stack trace, `ls -R`, a verbose build. That's ordinary terminal use, almost completely ordinary text. A terminal is a stateful protocol, as you hopefully know. If a mode change is in the dropped span (alt screen, bracketed paste, mouse tracking, kitty keyboard flags, a scroll region), the app and the terminal disagree for the rest of the session and nothing resyncs them short of a full RIS. The line-based skipping also can't be made correct even in principle, because terminal state isn't line-local. SGR persists across lines, cursor position depends on every CR/BS/tab/wide char before it, and full-screen apps don't emit newlines at all, they use CUP. I repeat: none of this is shade. "Greedy, drops data, trades correctness for speed" is fine. It's just a different category from a terminal emulator, and I would highly recommend you do not call it that. And again, I hope you understand especially at this point, that I'm giving this feedback in an earnest way attempting to educate and help. I would give the feedback the same way to anyone who works with me. Good luck with your project.