I'll add technical section to readme, but for short. I've used tui-rs[1] with crossterm[2] backend (which handles the actual terminal interaction). The docs may seem intimidating, but it's surprisingly easy to use.
I've considered using curses, but tui-rs seemed that it will be easier to handle. I can certainly recommend it for making tui applications.
I didn't actually use any documentation at all, it wasn't in the man page and I didn't feel like hunting for it, as it was pretty easy to understand just by looking at the output.
OK thanks, that's helpful! It looks like a lot of the newer terminal rendering library use "diff" style of rendering like web frameworks, rather than something more stateful like curses?
Is that why you thought it would be easier? You just update the entire page on every action, and it takes care of the details of coming up with the minimal terminal codes?
----
This is only tangentially related, but for those interested in programming in obscure languages, I recently discovered ble.sh which is a 30K+ line TUI for bash written in pure bash! It does basically what the fish shell does, so it has a terminal rendering library, utf-8 decoder, terminal decoder, bash parser with an AST, etc. all in bash.
Yes, my priority was making the UI done as fast as possible, as I wanted to focus on making the debugger and didn't want to think too much about UI. I looked at some examples of both of them and decided that tui-rs looks easier to use, it takes care of everything for me. Note that I might be wrong, I didn't spend even half an hour looking at the frameworks.
Another reason, albeit really small, was that tui-rs was written specifically for rust, and curses framework I looked into were essentially just C bindings, making it a bit weird to use. To be fair, this disadvantage is by far outweighed by the fact that curses is far more popular than tui-rs, and there is so much more tutorials and documentation to be found about it.
But I wanted to focus on writing the debugger, so I went with what seemed to be more convenient option and paid the price of lower control and performance - for example I have troubles implementing syntax highlighting because tui-rs tries to be clever with mine ansi escape codes.
---
Thanks for the links, especially the ble.sh looks amazing.
I've considered using curses, but tui-rs seemed that it will be easier to handle. I can certainly recommend it for making tui applications.
I didn't actually use any documentation at all, it wasn't in the man page and I didn't feel like hunting for it, as it was pretty easy to understand just by looking at the output.
Sed debug works by running the code specified just as normal, but it annotates what it does to stdout. So it might look like this: https://gist.github.com/SoptikHa2/a50e90bd1b34c7238944c20d1a...
Sed actually has pretty well-designed interface IMO, it's pretty minimal and has no nasty surprises.
Edit: Here[3] is something I've written about it.
[1]: https://github.com/fdehau/tui-rs [2]: https://github.com/crossterm-rs/crossterm [3]: https://soptik.tech/articles/building-desed-the-sed-debugger...