It surely is impressively well made. I am wondering though whether Charm actually qualifies as a text-based interface. Isn't it more like a replication of a graphical user interface, with windows and tabs etc.? If one's issues with working on the command line has always been that there are no "drawn" windows GUI elements, then this of course is a revelation, but we already have high-res versions of Charm, i.e. modern windows-based OSs.

There is no doubt, is a text based interface. The common term is text user interface (TUI vs GUI), and every app rendered as characters in a shell have been always considered TUI, whether they had windows, tabs, dropdowns and whatnot

OK. Then I probably should have asked whether there is anything gained by "drawing" a GUI with characters. Don't get me wrong, I spend most of my day on the command line. But I never thought "this would be so much better if it was more like windows / mac os".

I do think so. Terminal applications tend to be really accessible.

You said accessible, so would you expect terminal applications to work with screen readers for example? What about localisation?

I did not mean that kind of accessible. I mean easy to get, easy to install, easy to manage, easy to distribute.

apologies then! i dont understand how a tui app is necessarily get-able or installable or distributable. system package managers are more than capable of managing GUI apps, and a GUI can be distributed by uploading a zip to gh releases, just as a TUI app can be.

> would you expect terminal applications to work with screen readers for example

Can you explain to me any way in which they might not, bearing in mind they're basically text.

It's not automatic, any sufficiently complex interface will need to offer some kind of support. E.g. if your widget library offer dialogs, using e.g. ncurses, then TAB shouldn't allow you to flow out of such dialog. If you render graphic elements with special characters (dots, dashes or unusual glyphs), you would need to offer some hints to the screen reader to skip or identify differently that stuff. Just "read them out loud because is text" wouldn't work. It's been a long time since my last complex TUI so I don't know what's there today for accessibility

I did a quick Google for examples, and found this comment [0] on HN which gives some examples.

It being "basically text" doesn't matter; a pdf can be mostly just text but that doesn't mean in any shape or form that it's searchable.

[0] https://news.ycombinator.com/item?id=17683719

> I wonder if there is space for a new text-based web browser that adopts some of the design features showcased by Charm

Not sure if you're aware, but older protocols are still around to be used for this use case, and Gopher has even had a bit of a resurgence as of late

A Gemini client might benefit:

https://gemini.circumlunar.space/

Not using Charm, but I've designed a TUI Gemini client in Go! It's pretty popular, for terminal clients at least.

https://github.com/makeworld-the-better-one/amfora

I miss a search function, but thanks for your client. I may write one a la av98, but with jimtcl instead of Python3. It makes really easy to write networked stuff, either with TLS or not. I wrote a finger client in minutes.

Aren't Gemini pages static-by-design? It would be hard to do something really interactive / state-preserving with them if I'm not mistaken.