People tend to conflate the concept of text based interfaces with terminals and curses but it's possible to have text interfaces without curses. Most plan 9 applications have text interfaces but do not use terminals.
Windows in plan 9 are images that are drawn to. There are libraries for drawing fonts and various shapes.
Another thing that get conflated with text interfaces is keyboard control. For whatever reason the plan 9 developers were very adverse to this and preferred mouse based interaction.
Anyway plan 9 is interesting because of how it's different. If you're approaching it asking "Where's emacs and vim?" or "Why can't I get my shell history by pressing up?" you're probably not getting the full value out of it. Part of the problem is probably that it's close enough to unix to make people put unix expectations on it.
Here's a video about acme, a programmer's interface for plan 9.
Thanks for the long reply, though I must admit I'm aware of all that. I was hoping for some surprise information.
Your comment of it seeming like Unix might be the key point to take away. I know that I'm supposed to search in the buffer for history and use the mouse to select and rerun it, but having tried it multiple times, I cannot get comfortable with a mutable terminal buffer. That's also why in Emacs I only use term and not the editable terminals. Maybe one day I'll get comfortable.
Curses has nothing to do with the unix philosophy, and "terminal application" should not be confused with what is actually characteristic of unix: its IPC and IO model, and its possibilities for composing programmes through those. The fact that you most often utilise these features through a terminal emulator that runs a shell does not mean that curses and the ilk are essential to unix because they happen to draw interfaces in those terminal emulators. Curses it not more or less unixy than any other windowing/UI-widget library.
I don't understand what you're replying to. I didn't say curses==unix. Most terminal based applications use curses, therefore the lack of it limits the pool of applications.
What you lose is VT escape sequences, a hack to try to make TUI's when there was no alternative. In Plan9, your terminal windows naturally transition to be fully fledged GUI's when needed.
Also note that there is vt (at least on 9front), a terminal emulator for plan9, if you really want to use such applications. There's ssh too, if you need it.
A thing I forgot to mention: this means that if you "cpu" into another host, you can run text based commands, but you can also start the browser, mothra, or even doom in the same window. There is no difference between telnet and x forwarding on plan9.
vt(1) [1] is a terminal emulator installed on Plan 9 which can emulate a vt100 for any program which needs it. So you have something which can give you curses if you want it.
That's because the OSes on which plan9port runs already have plenty of apps that can emulate a vt100.
Your question suggests to me that you still don't get it: nothing in Plan 9 -- not the shell, not the ability to issue command lines and get stdout and stderr back -- depends on vt(1). vt(1) is used only to communicate with (tty drivers on) other OSes, over the network.
Just as most of time, a user of OS X has no need for an X server, most of the time, a Plan 9 user has no need for vt(1) or for ncurses.
I'm not suggesting you give Plan 9 a try BTW: on its best day ever, it had fewer than 1000 users, and if it was ever going to break 1000 users, it would have done so by now. The whole OS (excluding some fonts) has been available under an OSI- FSF- and DFSG-approved license since 2002.
So for example, Plan 9 will almost certainly never have a web browser capable a delivering a satisfactory experience on more than half of the 1000 most popular web sites -- because porting such a web browser to Plan 9 would cost 10s of millions of dollars in programmer time, and no one is going to spend that money to get fewer than 1000 new users.
There is a potential path. Someone builds a killer app that uses a 9p mechanism to deliver content, or else a better experience for an existing app. With this done, a browser decides to implement drawterm as a browser mode. Once you had that, it could start challenging html/css/javascript.
Agreed, and I know, so I should have said my use case is more with plan9port which is used with existing Unix applications. Therefore I had the desire to open a special win in acme that would support some level of tty emulation.
