Live data from Hacker News

The terminal of the future

jyn.dev

121–130 of 174 posts

Re: The terminal of the future

#121

Earlier quoted context omitted.

And GNU screen, and GNU Emacs and Vi and ...

If we are going to broaden this to Screen and its "TUI" style features, then the most complete effort at a programmable TUI in the Linux space I've seen is `desktop-tui`. https://github.com/Julien-cpsn/desktop-tui It is incomplete but takes what is almost a side aspect of TWIN and runs with it. https://github.com/cosmos72/twin TWIN is nearly 20 now and does quite a lot. It even has a Wikipedia page. https://en.wikipe…

I ment programs that implement persistent (shell) sessions.

Re: The terminal of the future

#122
post #32

Earlier quoted context omitted.

Emacs also has Org-mode and org-babel, which can work a lot like a Jupyter notebook, and can even talk to jupyter kernels. I do a lot in Emacs, especially now that I'm comfortable with GPTel. I open a poorly aligned, pixelated PDF scan of a 100+ year old Latin textbook in Emacs, mark a start page, end page, and Emacs lisp code shells out to qpdf to create a new smaller pdf from my page range to /tmp, and then adds th…

> This 1970s vintage text editor is also a futuristic language learning platform, it blows my mind. and all it took was a deep understanding of software development, experience with lisp and a bunch of your own time coding and debugging! what a piece of software!

Many HN readers grok software development, would likely get a kick out of learning Emacs Lisp, and have time to invest in coding and debugging. Emacs is not as clumsy or random as modern user-hostile software -- it's an elegant tool for a more civilized age, and as such is not for everyone.

Re: The terminal of the future

#123
post #74

Why does the successor to the terminal need to be text oriented at all? Maybe it is an API. Maybe the kernel implements this API and it can be called locally or remotely. Maybe someone invents an OAuth translation layer to UIDs. The API allows syscalls or process invocation. Output is returned in response payload (ofc we have a stream shape too). Maybe in the future your “terminal” is an app that wraps this API, auth…

> Heresy warning. Maybe the inputs and outputs don’t look anything like CLI or stdio text. Maybe we move on from 1000-different DSLs (each CLI’s unique input parameters and output formats) and make inputs and outputs object shaped. Maybe we make the available set of objects, methods and schemas discoverable in the terminal API. This is Powershell. It’s a cool idea for sure. One thing I’ve noticed though is that it be…

[deleted]

Re: The terminal of the future

#124
post #32

Earlier quoted context omitted.

Emacs also has Org-mode and org-babel, which can work a lot like a Jupyter notebook, and can even talk to jupyter kernels. I do a lot in Emacs, especially now that I'm comfortable with GPTel. I open a poorly aligned, pixelated PDF scan of a 100+ year old Latin textbook in Emacs, mark a start page, end page, and Emacs lisp code shells out to qpdf to create a new smaller pdf from my page range to /tmp, and then adds th…

As a non Emacs user, I would be really interested in a full writeup of how this works.

I'm hoping to prepare a presentation on how I use Emacs for language learning for Emacs Conf 2026. There are a couple of talks for I'm very much looking forward to this year's conference[0] (happening in less than a month!) and specifically this talk[1] on language learning with Emacs.

[0]: https://emacsconf.org/2025/talks/

[1]: https://emacsconf.org/2025/talks/languages/

Re: The terminal of the future

#125
post #74

Why does the successor to the terminal need to be text oriented at all? Maybe it is an API. Maybe the kernel implements this API and it can be called locally or remotely. Maybe someone invents an OAuth translation layer to UIDs. The API allows syscalls or process invocation. Output is returned in response payload (ofc we have a stream shape too). Maybe in the future your “terminal” is an app that wraps this API, auth…

> Why does the successor to the terminal need to be text oriented at all?

Terminals are not "text oriented". They are based on a bidirectional stream of tokens - that can be interpreted as text, or anything else.

That simplicity allows for Unix-style composition. If you make the output something different, then the receiving program will need to be able to parse it. The Amiga OS had some interesting ideas with different data types as system extensions - you'd receive "an image" instead of a JPEG file and you could ask the system to parse it for you. In any case, that's still forcing the receiving program to know what it's receiving.

One way to add some level of complexity is to add JSON output to programs. Then you can push them trough `jq` instead of `grep`, `sed`, or `awk`. Or push it through another tool to make a nice table.

> it’s all legacy invented for a world that is no longer relevant.

I hear that since the Lisa was introduced. Character streams are a pretty common thing today. They are also very useful thanks to their simplicity. Much like Unix, it's an example of the "worse is better" principle. It's simpler, dumber, and, because of that, its uses have evolved over decades with almost no change to the underlying plumbing required - the same tools that worked over serial lines, then multiplexed X.25 channels, then telnet, now work under SSH streams. Apps on both sides only need to know about the token stream.

Re: The terminal of the future

#126
post #108
post #74

Why does the successor to the terminal need to be text oriented at all? Maybe it is an API. Maybe the kernel implements this API and it can be called locally or remotely. Maybe someone invents an OAuth translation layer to UIDs. The API allows syscalls or process invocation. Output is returned in response payload (ofc we have a stream shape too). Maybe in the future your “terminal” is an app that wraps this API, auth…

> Heresy warning. Maybe the inputs and outputs don’t look anything like CLI or stdio text. Maybe we move on from 1000-different DSLs (each CLI’s unique input parameters and output formats) and make inputs and outputs object shaped. Maybe we make the available set of objects, methods and schemas discoverable in the terminal API. Entirely agree. Stdio text (which is really just stdio bytes) deeply limits how composable…

I have a distaste for the verboseness of PowerShell, but I also have concerns with the attempt to bake in complex objects into the pipeline. When you do that, programs up and down the stream need to be aware of that - and that makes it brittle.

One key aspect of the Unix way is that the stream is of bytes (often interpreted as characters) with little to no hint as to what's inside it. This way, tools like `grep` and `awk` can be generic and work on anything while others such as `jq` can specialize and work only on a specific data format, and can do more sophisticated manipulation because of that.

Re: The terminal of the future

#127
post #28

Great thought provoking article! Indeed, typing commands on the command line feels primitive like typing code into interactive interpreters (python, irb, etc.). Those are primitive REPLs. With lisp REPLs one types in the IDE/editor having full highlighting, completions and code intelligence. Then code is sent to REPL process for evaluation. For example Clojure has great REPL tooling. A variation of REPL is the REBL (…

> It could be interesting to see if it would be enough to add shell history as a completion source.

Fish shell does this too

Re: The terminal of the future

#128
post #84
post #74

Why does the successor to the terminal need to be text oriented at all? Maybe it is an API. Maybe the kernel implements this API and it can be called locally or remotely. Maybe someone invents an OAuth translation layer to UIDs. The API allows syscalls or process invocation. Output is returned in response payload (ofc we have a stream shape too). Maybe in the future your “terminal” is an app that wraps this API, auth…

> Why does the successor to the terminal need to be text oriented at all? I think because we already have non-text based terminal succesors. I think there is interest in a succesor to text-bassd because a lot of people both like them but the space has been rather stagnant for a while. To put it bluntly, what if its nothing like you ever imagined isn't all that interesting as speculation because it doesn't commit to a…

> I think because we already have non-text based terminal succesors.

We've had them for a long time. There have been multiple graphics standards terminals supported - Tektronix, ReGIS, Sixels, up to richer, less successful interfaces (such as AT&T's Blit and its successors - all gorgeous, all failed in the marketplace).

The notebook interface popularized by iPython is an interesting one, but it's not really a replacement for a terminal.

Re: The terminal of the future

#130
post #4

Earlier quoted context omitted.

I mean, what is a terminal emulator? It's a program that displays the output of other programs "inside" it. Terminal emulators display grids of characters using all sorts of horrifying protocols. Web browsers display html generated by other programs.

> Terminal emulators display grids of characters using all sorts of horrifying protocols. What sort of "horrifying protocols"? The entire VT220 state machine diagram can be printed on a single letter- or A4-sized sheet of paper. That's the complete "protocol" of that particular terminal (and of any emulator of it). Implementing the VT220 with a few small extensions (e.g., 256 colors or 24-bit colors) wouldn't be too…

> VT220 state machine diagram can be printed on a single letter- or A4-sized sheet of paper.

Does it cover Tek and ReGIS? Where can I find it?

Post reply on HN