> > I am open for being corrected

> No. No you're not. Because you keep shifting goalposts and ignoring inconvenient truths.

I still am. Please submit a PR to refterm to that implements the VT sequences I mentioned above, until then I must continue to believe that you just repeat what other people say, without using your own brain. Shifting goalposts is probably not the best wording here. I keep listing arguments.

> First you claimed that "almost none of the techniques "he" brags about can be applied to a real terminal". > > To which I linked and quoted Windows Terminal team: "We actually took the same approach Casey suggested. A lot of terminals implement it that way."

"Almost none" does not mean "none". What WT applied is related to the tiling renderer. And I am sure I said "isn't that bad as a product" with respect to that. But Cassay also said that such things are super basic (if you know about it).

> Then you shifted the goalpost to saying "We should distinguish here between renderer and VT terminal backend." > > To which I replied: he implements VT parsing and rendering. > > Is it a complete VT parsing and rendering pipeline? No. Does it invalidate his approach? No.

VT parsing and actually doing something based on it, how often do I need to write that until you do understand that (!?), are two entirely different things. VT parsing is done in refterm, because it's needed for SGR and CUP, obviously. But everything else is discarded. All the other VT sequences that are parsed are not interpreted. Again, Please implement the VT sequences I mentioned above in refterm, without degradation of refterms claims.

> And to put this into additional perspective, Windows Terminal was abysmally slow with no VT parsing, and with no color output to begin with. It couldn't handle most of Unicode, wide characters and dozens of other things.

You use Cassays wording here. I'm fine with that, WT was and is in fact still slow. Just fork it, and make it faster. You guys keep saying it's simple, it's easy, it's all proven numerous times. Yet noone of you ever provided a terminal that is implementing enough VT sequences to be taken serious. refterm is a joke, it's garbage, and simply harmful. Not to its entirety, certainly not, it prove a point on rendering speed (7000 frames per second in a terminal-like application). Ignoring the usefulness of such for a moment, the reason why this whole rant of Cassay and his demo program is harmful to the public is, because you keep blindingly following him. Without questioning, without thinking about it, because thinking costs energy, one could say. I do not know your true reasons, but I can just encourage you to try.

I HEREBY CALL YOU OUT! Please work on refterm, and proof your point by implementing:

1. DECSTBM, DECSLRM 2. SM/RM/DECRQPM 3. alt-screen 4. DL, ICH, IL 5. rectangular operations (DECCRA, DECFRA, DECRQCRA, ...) 6. SD, SU (respecting margins set by DECSTBM) 7. DECAWM correctly applied.

> Tell me, are you perhaps on Windows Terminal team?

I am not part of Microsoft nor their WT team. I do however know how terminals work internally, because I have implemented one. So I do know what I am speaking about here. I even took refterm very serious and looked into the source code and tried to learn from it. Again, I was already saying repeatively that there are some good techniques applied, and also has some architecturally good decisions. But this does not hold on the performance level when you actually start implementing more than just bling-bling SGR plus CUP. Ignoring DECAWM is also a damaging descision.

> But wait, don't tell me. I'm definitely not going to engage in this useless thread any longer.

Because I call you out? That's cheap. Please at least have the balls and react on the actual content of my post (the VT sequences): technically!. Until then I must just assume you are (amongst...