On Sat, Feb 11, 2012 at 02:53:00AM +0100, Guillaume Quintin wrote: > @Kurt: So how do you see a terminal emulator? > Something that can execute postscript or a > subset of it or another stack language? Maybe > simplier than NeWS if you do not need multi > monitor, thread, ...?
When I was (extraordinarily) young, terminals were far more pleasant to use than any terminal emulator is today. This ncurses lowest-common-denominator shit sucks real bad, especially when you got to spend any amount of time with a 'smart' terminal. Menus and text entry fields and such were first-class entities; to update the menu (which the terminal natively handled) you sent a signal that here comes a menu! and then you sent the menu and let the terminal worry about what to do with it. In a lot of ways it was almost like what html and user-css were supposed to be before the photoshop drones took over the web. In the sdl-based system I started working on*, it worked similarly. There wasn't a shitty typewriter interface, and menus and lists weren't presented as a sequence of fucked up control characters. In what I would consider to be a good interface, there's no character-based anything. There's a real text editor (which I implemented* as a subset of ex commands), and that text editor was in a permanent but resizable window at the bottom of the screen. You edited your text, and you sent it in one chunk. The server-side part (local or streamed over ssh) then takes that chunk and evaluates it. this means you can e.g. write a ten-line little shell script in one go and fire it off. Output was returned to the top half of your screen, a keystroke switched that to a display of stderr. The output half was a full-fledged searchable pager like less. Input chunks were logged along with their output, so you could page back through input sessions and see what the resultant output was. Input comands were logged locally; you could page through your 'history' and call up previous scripts, for instance, so you could edit them and fire them back off. Output (including things like updating menus) was sent as real, serialized data structures, which the client side would display appropriately, without some stupid stty garbage. If a stream of text was a serialized menu, then the menu bar between input and output was updated. None of that was compressed, well-serialized, or fault-tolerant, because I'm not a programmer. The program never really got much farther than being a half-assed text editor underneath a one-line pine-like menu, with rudimentary mouse support. But you could scroll through history, hit tab on an entry, and see the output from that command highlighted in the output side. Same for stderr output. I had planned* to figure out a decent way to serialize things like simple graphics; the plan was*, for instance, if a user wanted to show a picture or movie or whatever**, the input side resized to one line and the output side was replaced with a display of the whatever. In a perfect world you could even put a web page up there. When the 'application' or the image display or whatever exited you were returned to your terminal; if you've ever used rio you know how this 'program takes control of the terminal window' shit was set up in my head*. For interacting with regular brain-dead unix shells, the idea was just to send off commands in the shell's language and the client could do the 'mapping' between input and output. Obviously ncurses stuff and the like would just shit the bed, and when I started thinking "maybe my terminal could interpret ncurses code and present a proper interface!" I realized I had fallen into the pdcurses[1] trap and realized that was going to keep happening to me. The only way to fix the stupid interfaces endemic to unix is to scrap all of them and do it right... which is how we got into this mess. Of these features the two whose absence piss me off are: - a real, first-class text editor as the input method - no easy way to separate but quickly toggle between stdout and stderr So that's what I want in an interface. Maybe one day when I don't have kids to raise and bills to pay I'll have the sort of copious time required to developing something really good. That day won't be anytime soon. * - this was before I realized I'm not a developer and stopped wasting my time. ** - the 'server' side of this program could easily be on the local machine, or set as a shell on the remote end of an ssh connection. [1] http://pdcurses.sourceforge.net/