Re: [dev] [st and terminals] About escape sequences and stuff

From: Kurt H Maier <>
Date: Fri, 10 Feb 2012 23:20:59 -0500

On Sat, Feb 11, 2012 at 02:53:00AM +0100, Guillaume Quintin wrote:
> _AT_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

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

* - 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.

Received on Sat Feb 11 2012 - 05:20:59 CET

This archive was generated by hypermail 2.3.0 : Sat Feb 11 2012 - 05:24:04 CET