✳flâneur — a map of the web's best reading

the terminal of the future

jyn.dev · 3,222 words · saved by 1 readers

Terminal internals are a mess. A lot of it is just the way it is because someone made a decision in the 80s and now it’s impossible to change. —Julia Evans This is what you have to do to redesign infrastructure. Rich [Hickey] didn't just pile some crap on top of Lisp [when building Clojure]. He took the entire Lisp and moved the whole design at once. —Gary Bernhardt At a very very high level, a terminal has four parts: I lied a little bit above. "input" is not just text. It also includes signals that can be sent to the running process. Converting keystrokes to signals is the job of the PTY. Similar, "output" is not just text. It's a stream of ANSI Escape Sequences that can be used by the terminal emulator to display rich formatting. I do some weird things with terminals. However, the amount of hacks I can get up to are pretty limited, because terminals are pretty limited. I won't go into all the ways they're limited, because it's been rehashed many times before. What I want to do inste

Table of contents a mental model of a terminal what does a better terminal look like? a first try: Jupyter some problems how does that work? shell integration long-lived processes interacting suspending disconnecting rerun and undo/redo derived features needs a Jupyter notebook frontend needs shell integration needs sandboxed tracing ok but how do you build this stage 1: transactional semantics stage 2: persistent sessions stage 3: structured RPC stage 4: jupyter-like frontend jyn, what the fuck bibliography This post is part 6 of a multi-part series called “the computer of the next 200 y

Explore this link on the map →

related reading