[throwanem]

I also like having CLI tools that only work properly in the same terminal the developer uses! Browser incompatibility was such a reliable source of joy back in the Bronze Age days of web dev - I've missed it, and I'm really glad to see lots of smart folks doing the incredibly worthwhile work of reinventing the same concept for a new generation.

(It's an impressive achievement on a technical level, sure. But that's orthogonal to whether it's useful, and for practical purposes it's not. "Any tty will do" is a good thing.)

[willm]

It will run just on just about any terminal on any OS. Only standard xterm escapes are used.

You might find a really old terminal emulator where it struggles, but it would be the exception and not the rule.

[throwanem]

I feel like it's not been that long ago that I ran into trouble with "standard xterm escapes". As I recall, there are a lot of those, and many of the more interesting ones are at best very unevenly supported across terminals. The last such experience is in fact what led me to avoid doing anything more complicated in a terminal than basic colors and a few emoji.

That said, if your terminal support is as good as advertised, it probably shouldn't be hard to surface that on your site. (If you really want to sell me on it, let me try it out in a web-based terminal emulator like xterm.js! Then let me package up that test script for download, so I can easily run it locally in my terminal, as many of them as I like, and see for myself how well it works there.) Maybe also include feature coverage in your test suite and even CI, although that's definitely a trickier engineering problem.

As it is, I'd be very hesitant to use the library since doing so would risk incurring a dependency (on the user using a supported terminal) that wouldn't be easy to characterize more closely than "I tried this in xterm, y, and z and it worked, but if it breaks for you I'll have no immediate idea of why, and I'll have to choose between #wontfix and losing velocity on feature work."

[wasi_master]

I have been using textual extensively inside Visual Studio Code which uses xterm.js behind the hood [1], so far everything except hyperlinks works flawlessly, and hyperlinks don't obstruct anything either, it just shows as plain text. All 256 tests pass on my machine and the coverage based on lines of code is 42%, but you have to keep in mind that this project is still in beta [2] so that number is going to change

Also since the project is based on rich from the same author, some of the terminal features are from rich and the test coverage on that is 99% [3].

[1]: https://xtermjs.org/#real-world-uses

[2]: https://github.com/Textualize/textual#textual:~:text=Current....

[3]: https://app.codecov.io/gh/Textualize/rich

[throwanem]

Yeah, that's fair. The perils of reading code on a busy Sunday, I suppose - I didn't get as far as noticing that Textual has basis in a much more heavily used and tested library, and that definitely changes my evaluation.

Thanks for the steer!

[wasi_master]

No worries, cheers!

[tux1968]

But this appears to work in any terminal, not just the developer's. Or did I miss something?

[throwanem]

I grant the claim is that it works perfectly in any terminal. I see no evidence of that, and my experience with the complexities of terminals leads me to find the claim quite difficult to credit.

[mwt]

Why waste time making up a weird claim and then arguing against it? The author told you, personally and directly,

> It will run just on just about any terminal on any OS.

It's not hard to imagine it being rigorously tested on several platforms with modern CI tools. It's borderline disrespectful for you to immediately assume that the author has only ever tested it the specific terminal(s) he happens to develop in.

[throwanem]

I assumed my mild hyperbole would need no explanation, but perhaps that was optimistic. Conceding the author's claim as he made it and you quote it, I think there's still a discussion to be had here.

> It's not hard to imagine it being rigorously tested on several platforms with modern CI tools.

It's not hard to imagine a lot of things! But when I looked at the repository earlier [1], I saw a very thin unit test suite that hasn't been touched in eight months, and very little evidence of CI in use at all - and, of course, what checks there are can only exercise the apparently small subset of logic that the unit tests cover. Certainly, if there's anything examining actual behavior in any terminal environment, I saw no sign of it.

Perhaps you'll be able to point me to what I missed. Assuming I didn't, though - for a UI framework that seems designed to have me build my entire application on top of it, this doesn't really inspire a great deal of confidence. As I mentioned above, the risk is that if it turns out to support many fewer terminals than claimed, I'm forced to choose between at minimum significant and potentially near-total rework, or telling those of my users who have terminal-related trouble that I can't spare the time to support them.

If this were a pure open source project, I wouldn't raise this issue in this way. (I'd more likely spend some time looking at how I might build the basis of a CI setup like the one I describe - that might be a fun project, assuming I could find the focus time to spend!) But Textualize appears to be a company which is currently hiring, and which I assume intends at some point to sell some product or service. I think that makes it fair to apply a similar standard here to the sort I use when vetting any vendor. What would you have me do instead? Use kid gloves, and implicitly insult the team behind this project with the assumption that they can't fairly be expected to live up to a standard like that?

I grant they're an early-stage startup, maybe still a one-man band at this point, and likely haven't had time to get to the kind of detailed testing I'm asking about. That's fair, but that also leads one to suggest that the claims being made at this stage are somewhat ahead of what can reasonably be supported. I'd be a little hesitant about that personally, but then again it's not my company, my product, or my project.

[1] https://github.com/Textualize/textual/tree/main/tests

[mwt]

We simply have a different perspective on this. You see a TUI and have experience in the "Bronze Age" of the Internet in which browsers were not so stable across platforms/etc. and think that this more or less just doesn't work. I suspect peoples' experiences using it for a while now won't sway you; you are more than welcome to assume everything works only on one computer and is reliably broken elsewhere. I don't care what you choose to build your company with but I personally find this attitude towards new tools toxic and paralyzing. Hence my attempt at engaging to learn more.

From my perspective, I've used Rich in one of the very few contexts that practically matter (a terminal on macOS) and had a good experience. Will M. has been developing it in the open for a couple of years now and it's nearing critical mass in some parts of the Python ecosystem. If it was a diaper turned into a Molotov cocktail, it simply wouldn't the adoption it has so far. It probably runs fine on the three major operating systems of today, which is pretty much what a TUI needs to do. I have no idea if it runs smoothly on a Commodore 64 and to be honest I don't really care.

> Perhaps you'll be able to point me to what I missed.

You could have a look at Rich itself, which is what Textualize uses: https://github.com/Textualize/rich. I don't build UIs but the number of files/LOC gives me a bit more confidence that my personal experience wasn't a fluke.

> If this were a pure open source project,

What's a "pure" open source project in your view? You can review the licenses of the projects yourself and determine if MIT is "pure" open source, or see what the company says about their plans with the project: https://www.textualize.io/what-we-do

> Rich, Textual, and many of our future projects will continue to be built in public, with an Open-source license.

[Epiphany21]

All of that is moot unless you've tested the software yourself and found it to be broken in certain terminal emulators.

I agree with your point that it's easy to write CLI software that relies on features not all terminals have, but it's almost equally easy to write simple and portable software and test it in the most used terminals.

[willm]

You’re looking at the master branch. Most of the work is in the CSS branch.

The xterm control sequences are well documented (https://www.x.org/docs/xterm/ctlseqs.pdf) and we’re using a very minimal subset. The only codes we’re using beyond setting colour and style are those that move the cursor. Compatibility is likely to be the same as any TUI built in the last couple of decades. I haven’t found a single terminal emulator were it doesn’t work, and I’ve tried as many as I can download for the Mac, Linux, and Windows.

Perhaps you’ve assumed we’re doing something particularly exotic with terminals, but it’s honestly not doing anything that any curses app doesn’t do.

[paisawalla]

"It will run just on just about any terminal on any OS" is an extremely tall claim and requires more than stating what's easy to imagine, in order to back it up. Xterm is not some kind of universal standard, it's a constructive definition.

I have a difficult time imagining what a test suite looks like that can exercise all the relevant test cases in, and correctly evaluate the output of, terminal emulators across all OSes. So to me, this statement probably means "we tried a few sample scripts in VMware at some point."

[throwanem]

I'd probably try to do it with some kind of dummy framebuffer I could capture to an image file, and then inspect that image for variance against a known good snapshot. It's an approach I've seen work well with mobile app e2e testing; I grant it's heavyweight and can be somewhat imprecise, but I can't think offhand what could be much lighter and still work as well.

To be clear, I realize I'm asking a good deal here, but I'm being asked a good deal here too. If I'm to consider building a production application on this or any platform, I need considerable confidence that that platform isn't flawed in ways that may prove to mean I'll have wasted what might be a great deal of work. And if I'm going to have to design against the assumption I may need to have the application still work even when the platform doesn't, why use that platform at all?