The terminal of the future(jyn.dev)
jyn.dev
The terminal of the future
https://jyn.dev/the-terminal-of-the-future
173 comments
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 the resulting PDF to my LLM context. Then my code calls gptel-request with a custom prompt and I get an async elisp callback with the OCR'd PDF now in Emacs' org-mode format, complete with italics, bold, nicely formatted tables, and with all the right macrons over the vowels, which I toss into a scratch buffer. Now that the chapter from my textbook in a markup format, I can select a word, immediately pop up a Latin-to-English dictionary entry or select a whole sentence to hand to an LLM to analyze with a full grammatical breakdown while I'm doing my homework exercises. This 1970s vintage text editor is also a futuristic language learning platform, it blows my mind.
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 the resulting PDF to my LLM context. Then my code calls gptel-request with a custom prompt and I get an async elisp callback with the OCR'd PDF now in Emacs' org-mode format, complete with italics, bold, nicely formatted tables, and with all the right macrons over the vowels, which I toss into a scratch buffer. Now that the chapter from my textbook in a markup format, I can select a word, immediately pop up a Latin-to-English dictionary entry or select a whole sentence to hand to an LLM to analyze with a full grammatical breakdown while I'm doing my homework exercises. This 1970s vintage text editor is also a futuristic language learning platform, it blows my mind.
> 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!
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.
> 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.
but why would they? what problems are they solving by being able to paste text into your web browsers address bar? or load a pdf into an LLM? or some other incredibly specific-to-you ability youve added?
if simply adding a lisp interpreter to a program is enough to impress people, why not add it to something other than 1970s terminal text editor? surely an LLM plus lisp can do more of these inane tricks than a 70s text editor plus lisp?
but why would they? what problems are they solving by being able to paste text into your web browsers address bar? or load a pdf into an LLM? or some other incredibly specific-to-you ability youve added?
if simply adding a lisp interpreter to a program is enough to impress people, why not add it to something other than 1970s terminal text editor? surely an LLM plus lisp can do more of these inane tricks than a 70s text editor plus lisp?
> what problems are they solving
For me, it's about making a repeated workflow efficient. Sure, I could alt+tab over to my PDF viewer, figure out the range of pages I want, then switch to my terminal window, run qpdf with the right arguments to split the PDF into chunks, alt+tab over to my web browser, log into Google's AI studio, mouse over add context to the LLM, navigate a file-open dialog to find my PDF, paste in my OCR prompt, have Gemini spit out my text, press download, navigate another file-open dialog, and then open the resulting file in my editor of choice.
Instead I can open my PDF, press a few keys, and have the whole process done for me without having to think too much about it and get back to wondering if this damn verb should be in the continual/habitual, completed, or more than completed past.
> why not add it to something other than 1970s terminal text editor?
We're responding to an article entitled "The terminal of the future", and even the GUI version of Emacs is still very much rooted in the paradigm of the terminal but with some very nice improvements. I'm arguing that much of the future this article pines for is already here.
For me, it's about making a repeated workflow efficient. Sure, I could alt+tab over to my PDF viewer, figure out the range of pages I want, then switch to my terminal window, run qpdf with the right arguments to split the PDF into chunks, alt+tab over to my web browser, log into Google's AI studio, mouse over add context to the LLM, navigate a file-open dialog to find my PDF, paste in my OCR prompt, have Gemini spit out my text, press download, navigate another file-open dialog, and then open the resulting file in my editor of choice.
Instead I can open my PDF, press a few keys, and have the whole process done for me without having to think too much about it and get back to wondering if this damn verb should be in the continual/habitual, completed, or more than completed past.
> why not add it to something other than 1970s terminal text editor?
We're responding to an article entitled "The terminal of the future", and even the GUI version of Emacs is still very much rooted in the paradigm of the terminal but with some very nice improvements. I'm arguing that much of the future this article pines for is already here.
> what problems are they solving
programmatic text manipulation
programmatic text manipulation
> or some other incredibly specific-to-you ability youve added?
You're saying this with derision, but the ability to quickly add "incredibly specific-to-you" features is precisely what is so cool about it!
You're saying this with derision, but the ability to quickly add "incredibly specific-to-you" features is precisely what is so cool about it!
“What is the point of a paint brush? Sure, an artist picks it up and paints a masterpiece, but I see no utility in that because when I pick it up, all I can paint are squiggly lines. Paint brushes are useless!”
its more like asking for a painting and being given a paintbrush, then told i was the reason the painting is shit
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/
[0]: https://emacsconf.org/2025/talks/
[1]: https://emacsconf.org/2025/talks/languages/
There's kinda not much to it. It's just that you have:
1. a full-fledged programming language
2. no namespacing (nothing is private)
3. no modern GUI concepts to take into account (no CSS `flex-direction`...)
4. no edit-compile-run cycle
5. people have written extensions for many decades
6. people always write extensions with the possibility in mind that their extensions may be extended
Then you can probably see how it works, with just your imagination!
Of course there's a number of epiphanies that may be needed... Like how the principle "compose many small Unix programs with text as the universal interface" is just like "compose many functions with return values as the universal interface", or that it isn't an editor and more like a terminal (with integrated tmux-like functionality) that you decided to turn into an editor, or that an editor waiting for text entry is just stuck in a `while`-loop of reading the next input character, what even is a shell, what even is a computer, etc etc.
1. a full-fledged programming language
2. no namespacing (nothing is private)
3. no modern GUI concepts to take into account (no CSS `flex-direction`...)
4. no edit-compile-run cycle
5. people have written extensions for many decades
6. people always write extensions with the possibility in mind that their extensions may be extended
Then you can probably see how it works, with just your imagination!
Of course there's a number of epiphanies that may be needed... Like how the principle "compose many small Unix programs with text as the universal interface" is just like "compose many functions with return values as the universal interface", or that it isn't an editor and more like a terminal (with integrated tmux-like functionality) that you decided to turn into an editor, or that an editor waiting for text entry is just stuck in a `while`-loop of reading the next input character, what even is a shell, what even is a computer, etc etc.
Yes, but what keystrokes and which packages are you using? Elpa versions or a fork from elsewhere?
> Acme:
Got a link to what you meant? This is pretty hard to search for.
> - Emacs
One thing in common with emacs, jupyter, vscode.. these are all capable platforms but not solutions, and if you want to replace your terminal emulator by building on top of them it's doable but doesn't feel very portable.
I'd challenge people that are making cool stuff to show it, and then ship it. Not a pile of config + a constellation of plugins at undeclared versions + a "simple" 12-step process that would-be adopters must copy/paste. That's platform customization, not something that feels like an application. Actually try bundling your cool hack as a docker container or a self-extracting executable of some kind so that it's low-effort reproducible.
Got a link to what you meant? This is pretty hard to search for.
> - Emacs
One thing in common with emacs, jupyter, vscode.. these are all capable platforms but not solutions, and if you want to replace your terminal emulator by building on top of them it's doable but doesn't feel very portable.
I'd challenge people that are making cool stuff to show it, and then ship it. Not a pile of config + a constellation of plugins at undeclared versions + a "simple" 12-step process that would-be adopters must copy/paste. That's platform customization, not something that feels like an application. Actually try bundling your cool hack as a docker container or a self-extracting executable of some kind so that it's low-effort reproducible.
> Got a link to what you meant? This is pretty hard to search for.
http://acme.cat-v.org/
http://www.youtube.com/watch?v=dP1xVpMPn8M
> *I'd challenge people that are making cool stuff to show it, and then ship it.
Emacs has the following builtin and more
- Org mode (with babel): Note taking and outliner, authoring, notebooks, agenda, task management, timetracking,...
- Eshell: A shell in lisp, similar to fish, but all the editor commands are available like cli tools.
- comint: All things REPL (sql client, python,...)
- shell-command and shell-mode: The first is for ad-hoc commands, the second is derived from comint and give you the shell in an REPL environment (no TUI).
- term: terminal emulator, when you really want a tui. But the support for escape sequences is limited, so you may want something like `eat` or `vterm`.
- compile: all things build tools. If you have something that report errors and where those errors are located in files, then you can tie it to compile and have fast navigation to those locations.
- flymake: Watch mode for the above. It lets you analyze the current file
- ispell and flyspell: Spell checking
- dired: file management
- grep: Use the output of $grep_like_tool for navigatoin
- gnus and rmail: Everything mail and newsgroup.
- proced: Like top
- docview: View pdf and ps files, although you can probably hack it to display more types.
- tramp: Edit files from anywhere...
And many more from utilities (calc, calendar) and games to low level functions (IPC, network,...) and full blown applications (debugger, MPD client). And a lot of stuff to write text and code thhings. All lisp code, with nice documentation. That's just for the built-in stuff.
If not for the state of the Web, you could probably just went straight from init to Emacs.
http://acme.cat-v.org/
http://www.youtube.com/watch?v=dP1xVpMPn8M
> *I'd challenge people that are making cool stuff to show it, and then ship it.
Emacs has the following builtin and more
- Org mode (with babel): Note taking and outliner, authoring, notebooks, agenda, task management, timetracking,...
- Eshell: A shell in lisp, similar to fish, but all the editor commands are available like cli tools.
- comint: All things REPL (sql client, python,...)
- shell-command and shell-mode: The first is for ad-hoc commands, the second is derived from comint and give you the shell in an REPL environment (no TUI).
- term: terminal emulator, when you really want a tui. But the support for escape sequences is limited, so you may want something like `eat` or `vterm`.
- compile: all things build tools. If you have something that report errors and where those errors are located in files, then you can tie it to compile and have fast navigation to those locations.
- flymake: Watch mode for the above. It lets you analyze the current file
- ispell and flyspell: Spell checking
- dired: file management
- grep: Use the output of $grep_like_tool for navigatoin
- gnus and rmail: Everything mail and newsgroup.
- proced: Like top
- docview: View pdf and ps files, although you can probably hack it to display more types.
- tramp: Edit files from anywhere...
And many more from utilities (calc, calendar) and games to low level functions (IPC, network,...) and full blown applications (debugger, MPD client). And a lot of stuff to write text and code thhings. All lisp code, with nice documentation. That's just for the built-in stuff.
If not for the state of the Web, you could probably just went straight from init to Emacs.
Emacs user of a highly customized and well-loved setup for over a decade before I gave up the habit ;) But this illustrates my point perfectly. That's a huge list of stuff that all needs to be turned on or configured in various ways. Some newbie who is shopping for a new terminal-emulator saw this, gave up immediately, and decided to download kitty because it looks like an app and not a platform.
To successfully argue that it's just perfect as a terminal emulator, I think you need to find a way to ship it in exactly that configuration. That would mean that you open it up to a shell prompt with a dollar sign, you can hit ctrl-t to get a new terminal tab. Clicking URLs should open them in a browser without having to copy/paste. Speaking of copy/paste, that should work too, and ctrl-e, and ctrl-a, etc, etc.
To successfully argue that it's just perfect as a terminal emulator, I think you need to find a way to ship it in exactly that configuration. That would mean that you open it up to a shell prompt with a dollar sign, you can hit ctrl-t to get a new terminal tab. Clicking URLs should open them in a browser without having to copy/paste. Speaking of copy/paste, that should work too, and ctrl-e, and ctrl-a, etc, etc.
I think we went past each other at some point. I was not arguing that you can use Emacs as a terminal emulator. I was talking more about terminals and shell being a way of computing. Emacs is an alternate way of computing.
With terminals, you have the escapes sequences, the alternate screen, the shell capabilities. With Emacs, you have a lisp VM with a huge library of functions and buffers. I still use a normal terminal like xterm and Terminal.app, but I have eat installed and it's working great.
With terminals, you have the escapes sequences, the alternate screen, the shell capabilities. With Emacs, you have a lisp VM with a huge library of functions and buffers. I still use a normal terminal like xterm and Terminal.app, but I have eat installed and it's working great.
I agree with you, once you have a terminal emulator like the one described in the post you are close to reinventing eMacs. Many have tried over the years, no one succeeded so far.
> Speaking of copy/paste, that should work too, and ctrl-e, and ctrl-a, etc, etc.
readline in bash and zle in zsh both default to the standard emacs bindings so you're covered there.
The emacs bindings also work in every Cocoa NSTextField on macOS.
As far as having to go and download and configure all of those, 1., you don't need to do any of that, and you certainly wouldn't need to do it all at the same time. Configuring one of those a month when you come across needing one, and you find something in the default config you don't like, is definitely doable. 2. Once you do figure out your configs, they end up in your init.el. emacs is preinstalled on macOS and a quick $pkgmanager installed emacs away on Linux. Beyond that you can ship your entire setup just by downloading your emacs.d directory or init.el.
The same goes for basically any text editor, modern or not.
readline in bash and zle in zsh both default to the standard emacs bindings so you're covered there.
The emacs bindings also work in every Cocoa NSTextField on macOS.
As far as having to go and download and configure all of those, 1., you don't need to do any of that, and you certainly wouldn't need to do it all at the same time. Configuring one of those a month when you come across needing one, and you find something in the default config you don't like, is definitely doable. 2. Once you do figure out your configs, they end up in your init.el. emacs is preinstalled on macOS and a quick $pkgmanager installed emacs away on Linux. Beyond that you can ship your entire setup just by downloading your emacs.d directory or init.el.
The same goes for basically any text editor, modern or not.
Doom Emacs is, I think, the answer here:
1. Install Emacs
2. git clone --depth 1 https://github.com/doomemacs/doomemacs ~/.config/emacs
3. ~/.config/emacs/bin/doom install
Now open Emacs and stuff just works. You can customize it later if you want.
I agree with your general point. People mostly want stuff that just works. Very few want to become experts (and nobody can be an expert in everything.)
1. Install Emacs
2. git clone --depth 1 https://github.com/doomemacs/doomemacs ~/.config/emacs
3. ~/.config/emacs/bin/doom install
Now open Emacs and stuff just works. You can customize it later if you want.
I agree with your general point. People mostly want stuff that just works. Very few want to become experts (and nobody can be an expert in everything.)
> To successfully argue that it's just perfect as a terminal emulator, I think you need to find a way to ship it in exactly that configuration.
As you know, Emacs is more of a super environment that’s personally customised to a single individual. It wouldn’t make sense to hand over a fitted suit to someone else who is twice your size of you and then say “put it on, it looks good on me”.
As you know, Emacs is more of a super environment that’s personally customised to a single individual. It wouldn’t make sense to hand over a fitted suit to someone else who is twice your size of you and then say “put it on, it looks good on me”.
> Got a link to what you meant? This is pretty hard to search for.
It's part of plan9:
https://en.wikipedia.org/wiki/Acme_(text_editor)
It's part of plan9:
https://en.wikipedia.org/wiki/Acme_(text_editor)
A solution build upon Emacs is trivially portable by utilizing a custom init.el, setting the user-emacs-directory variable, and a script/desktop entry running Emacs with it. A solution build upon anything is, in theory, portable utilizing Nix/Guix.
Since you mention Emacs, I'd like to point to one thing that really only Emacs has, and nothing else: If you implement your "app" with Elisp, it is truly UI independant. It will work in a terminal, and with a GUI. To my knowledge, there is no such thing elsewhere. I used to write a lot of Elisp, roughly 20 years ago. And I did it all in a terminal, because this is what I can use. And users of my code could use it in their GUI environment, without even knowing that I was coming from a plain text-mode background. Again, this is very special, and IMO there is no other "platform" around which can do that.
I think Neovim is more flexible -- a plugin you write for neovim can run in the terminal, in any Neovim GUI or in another application (like VSCode) that can embed Neovim.
I tried to use Neovim several times. However, it appears to not be very friendly for my usecase, which is using it with a Braille display. A lot of Neovim UI elements only use background/foreground color to indicate highlighted positions, instead of making use of the cursor. I couldn't even use the intial plugin menu. Emacs is much better in thsi regard.
i would describe the main idea of the post as opening up the data model of the terminal. the list of wishes are an example of things you can build once you've done that, not the primary reason that opening the data model is useful.
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, authenticates you to the server with OAuth, and can take whatever shape pleases you- REPL, TUI, browser-ish, DOOM- like (shoot the enemy corresponding to the syscall you want to make), whatever floats your boat.
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.
Terminals aren’t a thing of the 80s; they’re a thing of the early 70s when somebody came up with a clever hack to take a mostly dumb device with a CRT and keyboard and hook it to a serial port on a mainframe.
Nowadays we don’t need that at all; old-timers like me like it because it’s familiar but it’s all legacy invented for a world that is no longer relevant. Even boot environments can do better than terminals today.
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, authenticates you to the server with OAuth, and can take whatever shape pleases you- REPL, TUI, browser-ish, DOOM- like (shoot the enemy corresponding to the syscall you want to make), whatever floats your boat.
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.
Terminals aren’t a thing of the 80s; they’re a thing of the early 70s when somebody came up with a clever hack to take a mostly dumb device with a CRT and keyboard and hook it to a serial port on a mainframe.
Nowadays we don’t need that at all; old-timers like me like it because it’s familiar but it’s all legacy invented for a world that is no longer relevant. Even boot environments can do better than terminals today.
> 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 becomes closer to a programming language and further away from scripting (ie you have to memorize the APIs and object shapes). And at that point, why would you write the program in a worse programming language?
By comparison, I’ve noticed even windows-leaning folks do a better job remembering how to delete files and find files than doing so through cmd.exe or powershell. I think that’s because you can run the command to see the output and then you know the text transformation you need to apply for the next step whereas powershell shows you formatted text but objects in the pipe.
Maybe a better terminal that provided completion for commands with AI support and a uniform way to observe the object shapes instead of formatted text might mitigate this weakness but it is real today at least imho.
This is Powershell. It’s a cool idea for sure. One thing I’ve noticed though is that it becomes closer to a programming language and further away from scripting (ie you have to memorize the APIs and object shapes). And at that point, why would you write the program in a worse programming language?
By comparison, I’ve noticed even windows-leaning folks do a better job remembering how to delete files and find files than doing so through cmd.exe or powershell. I think that’s because you can run the command to see the output and then you know the text transformation you need to apply for the next step whereas powershell shows you formatted text but objects in the pipe.
Maybe a better terminal that provided completion for commands with AI support and a uniform way to observe the object shapes instead of formatted text might mitigate this weakness but it is real today at least imho.
> whereas powershell shows you formatted text but objects in the pipe
Somewhat true. However it's easy to explore what methods and properties are available. Just add `| gm` (Get-Member) to the end of your pipeline to see what you're dealing with and what's available.
Somewhat true. However it's easy to explore what methods and properties are available. Just add `| gm` (Get-Member) to the end of your pipeline to see what you're dealing with and what's available.
[deleted]
> 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.
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.
> 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.
That's still text. Even PowerShell passes objects between commands.
Plan9 did this correctly. A terminal was just a window which could run graphical applications or textual applications. Locally or remotely. It all worked. You create a window, you get a shell with a text prompt. You can do text stuff all day long. But maybe you want that window to be a file manager, now? Launch vdir, and now that same window is home to a graphical file browser. close that and remote into another plan9 machine. launch doom. it runs. it all just works, and it all works smoothly.
And the entire source code for that OS could fit into one person's brain.
It is a very simple OS, appears (to my layman eye) to have sandboxing between all applications by default (via per-process namespaces) making it very easy to keep one application off of your network while allowing others to talk via network as much as they want, for example.
That's still text. Even PowerShell passes objects between commands.
Plan9 did this correctly. A terminal was just a window which could run graphical applications or textual applications. Locally or remotely. It all worked. You create a window, you get a shell with a text prompt. You can do text stuff all day long. But maybe you want that window to be a file manager, now? Launch vdir, and now that same window is home to a graphical file browser. close that and remote into another plan9 machine. launch doom. it runs. it all just works, and it all works smoothly.
And the entire source code for that OS could fit into one person's brain.
It is a very simple OS, appears (to my layman eye) to have sandboxing between all applications by default (via per-process namespaces) making it very easy to keep one application off of your network while allowing others to talk via network as much as they want, for example.
> 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 your shell programs can be, since data and its representation are tightly coupled (they're exactly the same). I wrote a smidgin here[0] on my blog, but take a look at this unix vs. PowerShell example I have there. Please look beyond PowerShell's incidental verbosity here and focus more deeply on the profoundly superior composition that you can only have once you get self-describing objects over stdio instead of plain bytes.
Entirely agree. Stdio text (which is really just stdio bytes) deeply limits how composable your shell programs can be, since data and its representation are tightly coupled (they're exactly the same). I wrote a smidgin here[0] on my blog, but take a look at this unix vs. PowerShell example I have there. Please look beyond PowerShell's incidental verbosity here and focus more deeply on the profoundly superior composition that you can only have once you get self-describing objects over stdio instead of plain bytes.
$ # the unix way
$ find . -name '*.go' -not -name '*_test.go' -ctime -4 -exec cat {} \; | wc -l
7119
$ # the powershell way
$ pwsh -c 'gci -recurse | where {($_.name -like "*.go") -and ($_.name -notlike "*_test.go") -and ($_.LastWriteTime -gt (get-date).AddDays(-4))} | gc | measure | select -ExpandProperty count'
7119
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.
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.
> 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.
Yeah, you definitely can't write tools for the unix shell that assume some kind of self-describing message encoding. I mean, you could, but you'd have to do a lot of work to wrap it so that it can work with unix byte streams at the edges. I believe oil shell and nushell have prior art on this. To your point, it should be telling that those are shells of their own, rather than tools for existing unix shells.
> 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.
This seems backwards to me. grep and awk are extremely fragile because they have to look at what's inside. They have to read every byte, and the user of grep and awk must understand entirely what the incoming data will be.
Whereas with PowerShell or any other system with self-describing messages, the user makes some lightweight assertions about the abstract shape of the data--not the concrete shape of that data's representation.
Yeah, you definitely can't write tools for the unix shell that assume some kind of self-describing message encoding. I mean, you could, but you'd have to do a lot of work to wrap it so that it can work with unix byte streams at the edges. I believe oil shell and nushell have prior art on this. To your point, it should be telling that those are shells of their own, rather than tools for existing unix shells.
> 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.
This seems backwards to me. grep and awk are extremely fragile because they have to look at what's inside. They have to read every byte, and the user of grep and awk must understand entirely what the incoming data will be.
Whereas with PowerShell or any other system with self-describing messages, the user makes some lightweight assertions about the abstract shape of the data--not the concrete shape of that data's representation.
> When you do that, programs up and down the stream need to be aware of that - and that makes it brittle.
You can go from object- to good old text processing with *nix tools no problem.
Instead of using 100% PowerShell to count all lines in the text files:
You can go from object- to good old text processing with *nix tools no problem.
Instead of using 100% PowerShell to count all lines in the text files:
gc *.txt | measure | select -ExpandProperty count
gc *.txt | wc -l
What GP talks about is illustrated with the following modification of your example:
PS /home/user> gc *.txt | measure | cat | select -ExpandProperty Count
Select-Object: Property "Count" cannot be found.
Select-Object: Property "Count" cannot be found.
Select-Object: Property "Count" cannot be found.
Select-Object: Property "Count" cannot be found.
Select-Object: Property "Count" cannot be found.
Select-Object: Property "Count" cannot be found.
Select-Object: Property "Count" cannot be found.
Select-Object: Property "Count" cannot be found.
Select-Object: Property "Count" cannot be found.
> Essentially at every step you need to consider whether the preceding command outputs objects or not.
This is true, no matter what language, paradigm, or even universe you're in; data that gets passed into a pipeline needs to have the abstract shape that the pipeline expects. This is always true, and it's every bit as true of unix byte streams.
You can of course have pipelines that try to coerce data or assert its structure. The PowerShell example you showed does the latter, and raises an error message that the assertion failed.
Unix byte streams do neither. There's no coercion, no assertion. Just blind trust. When you have IFS set incorrectly, you simply get a wrong answer. When you grab the wrong field number with cut or awk, you get a wrong (or empty) answer. The input data matters every bit as much with unix as it does with every other system of computation. What changes are characteristics like brittleness and enforceability of invariants.
This is true, no matter what language, paradigm, or even universe you're in; data that gets passed into a pipeline needs to have the abstract shape that the pipeline expects. This is always true, and it's every bit as true of unix byte streams.
You can of course have pipelines that try to coerce data or assert its structure. The PowerShell example you showed does the latter, and raises an error message that the assertion failed.
Unix byte streams do neither. There's no coercion, no assertion. Just blind trust. When you have IFS set incorrectly, you simply get a wrong answer. When you grab the wrong field number with cut or awk, you get a wrong (or empty) answer. The input data matters every bit as much with unix as it does with every other system of computation. What changes are characteristics like brittleness and enforceability of invariants.
jcgl already answered this well. My example was merely to show that you can go from PS objects to old fashioned text processing without issues. Any non-PS tool will just receive the text representation of the objects – exactly as you see them in the terminal. I wasn't trying to imply you can go back and forth between them like magic (which should be obvious).
Once you have lost the objects and work with simple text, you have to use the text processing tools of PS, if that's what you want to do. To continue your example:
(Note: this example is nonsense, just to show that it works)
Once you have lost the objects and work with simple text, you have to use the text processing tools of PS, if that's what you want to do. To continue your example:
gc *.txt | measure | cat | sls count
(Note: this example is nonsense, just to show that it works)
[deleted]
Another question is if such pipelines should act on objects, or more structured text streams. Many programs can output json, is this a pragmatic way forward to extend and improve further?
Replying out-of-order to your points.
> Many programs can output json, is this a pragmatic way forward to extend and improve further?
Yes, json is a pragmatic way to put a band-aid on this issue. It really is Good Enough™ for many things, and shell tools that optionally emit json are strictly an improvement, imo.
> Another question is if such pipelines should act on objects, or more structured text streams.
"Structured text" is inherently brittle, compared to a self-describing message format. For one, even when you structure your text, you will always end up dealing with escaping problems.
Even worse, imo, is that backwards compatibility becomes a terrible challenge. Let me illustrate with a best-case scenario for structured text: ASCII-only tabular data (nested, binary, unicode data is left as an exercise to the reader, in true unix fashion). The most natural thing to do in unix is to select the relevant fields with awk. More specifically, you select fields by their number. Well, now your pipeline is tightly coupled to column ordering.
In principle you could use awk to select based on field names, those field names are just text and so it becomes incumbent on you, the pipeline author, to make sure they don't get lost in transit. No easy tail or grep for you!
All of this becomes avoidable when you deal with self-describing messages instead of raw bytes.
> Many programs can output json, is this a pragmatic way forward to extend and improve further?
Yes, json is a pragmatic way to put a band-aid on this issue. It really is Good Enough™ for many things, and shell tools that optionally emit json are strictly an improvement, imo.
> Another question is if such pipelines should act on objects, or more structured text streams.
"Structured text" is inherently brittle, compared to a self-describing message format. For one, even when you structure your text, you will always end up dealing with escaping problems.
Even worse, imo, is that backwards compatibility becomes a terrible challenge. Let me illustrate with a best-case scenario for structured text: ASCII-only tabular data (nested, binary, unicode data is left as an exercise to the reader, in true unix fashion). The most natural thing to do in unix is to select the relevant fields with awk. More specifically, you select fields by their number. Well, now your pipeline is tightly coupled to column ordering.
In principle you could use awk to select based on field names, those field names are just text and so it becomes incumbent on you, the pipeline author, to make sure they don't get lost in transit. No easy tail or grep for you!
All of this becomes avoidable when you deal with self-describing messages instead of raw bytes.
Plan9 shed the textual terminal baggage we all carry today, and it did so in 1995.
The terminal of plan9 was just a window. By default you got a shell with a textual prompt, but you can launch any graphical application in there or any textual application. you can launch a 2nd window manager with its own windows. you can run doom. you can `ls` and `ssh` all you like. it all just works.
this debuted in Plan9 in 1995 or so. 30 years ago we had the terminal of the future and the entire world ignored it for some reason. I'm still a bit mad about it.
The terminal of plan9 was just a window. By default you got a shell with a textual prompt, but you can launch any graphical application in there or any textual application. you can launch a 2nd window manager with its own windows. you can run doom. you can `ls` and `ssh` all you like. it all just works.
this debuted in Plan9 in 1995 or so. 30 years ago we had the terminal of the future and the entire world ignored it for some reason. I'm still a bit mad about it.
Totally agree with all of your comment. To solve for structured data instead of everyone writing parsers, I’ve enjoyed using nushell (not affiliated, just love the idea). https://www.nushell.sh/
It’s like powershell but not ugly and not Microsoft.
It’s like powershell but not ugly and not Microsoft.
I love the idea of nushell. Do you have any worry about the lack of portability of having and becoming so familiar with such a tool that you become reliant on it?
I have this feeling with most things that are not the "default", especially when I think of getting new tools adopted into a conservative workplace.
I have this feeling with most things that are not the "default", especially when I think of getting new tools adopted into a conservative workplace.
If you want to adopt it in your workplace, I would not recommend nushell. They have severe, long standing bugs which don't get fixed. The most annoying to me is output formatting:
https://github.com/nushell/nushell/issues/13601
https://github.com/nushell/nushell/issues/16379
https://github.com/nushell/nushell/issues/13601
https://github.com/nushell/nushell/issues/16379
> 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 any choices. The proposal has to be imaginable to be interesting.
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 any choices. The proposal has to be imaginable to be interesting.
> 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.
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.
Self-plug since you're my exact target audience: check out Terminal Click [0]. It's still early days though.
[0] https://terminal.click
[0] https://terminal.click
I looked at that link but didn’t understand what I was looking at and didn’t see a link that would give me an overview. I’d like to know more about it.
For sure, it's high on my TODO list to overhaul the site over Thanksgiving. If you scroll down a bit and play the 3-minute trailer you'll get the gist of it - pardon the inconvenience!
I dread reading these articles written by people who perceive the command-line interface / terminal / shell to be this archaic system, and propose "modernizing" it by cramming whatever UI/UX they're most familiar with.
The last thing a command-line terminal needs is a Jupyter Notebook-like UI. It doesn't need to render HTML; it doesn't need rerun and undo/redo; and it definitely doesn't need structured RPC. Many of the mentioned features are already supported by various tooling, yet the author dismisses them because... bugs?
Yes, terminal emulators and shells have a lot of historical baggage that we may consider weird or clunky by today's standards. But many design decisions made 40 years ago are directly related to why some software has stood the test of time, and why we still use it today.
"Modernizing" this usually comes with very high maintenance or compatibility costs. So, let's say you want structured data exchange between programs ala PowerShell, Nushell, etc. Great, now you just need to build and maintain shims for every tool in existence, force your users to use your own custom tools that support these features, and ensure that everything interoperates smoothly. So now instead of creating an open standard that everyone can build within and around of, you've built a closed ecosystem that has to be maintained centrally. And yet the "archaic" unstructured data approach is what allows me to write a script with tools written decades ago interoperating seamlessly with tools written today, without either tool needing to directly support the other, or the shell and terminal needing to be aware of this. It all just works.
I'm not saying that this ecosystem couldn't be improved. But it needs broad community discussion, planning, and support, and not a brain dump from someone who feels inspired by Jupyter Notebooks.
The last thing a command-line terminal needs is a Jupyter Notebook-like UI. It doesn't need to render HTML; it doesn't need rerun and undo/redo; and it definitely doesn't need structured RPC. Many of the mentioned features are already supported by various tooling, yet the author dismisses them because... bugs?
Yes, terminal emulators and shells have a lot of historical baggage that we may consider weird or clunky by today's standards. But many design decisions made 40 years ago are directly related to why some software has stood the test of time, and why we still use it today.
"Modernizing" this usually comes with very high maintenance or compatibility costs. So, let's say you want structured data exchange between programs ala PowerShell, Nushell, etc. Great, now you just need to build and maintain shims for every tool in existence, force your users to use your own custom tools that support these features, and ensure that everything interoperates smoothly. So now instead of creating an open standard that everyone can build within and around of, you've built a closed ecosystem that has to be maintained centrally. And yet the "archaic" unstructured data approach is what allows me to write a script with tools written decades ago interoperating seamlessly with tools written today, without either tool needing to directly support the other, or the shell and terminal needing to be aware of this. It all just works.
I'm not saying that this ecosystem couldn't be improved. But it needs broad community discussion, planning, and support, and not a brain dump from someone who feels inspired by Jupyter Notebooks.
I cannot agree more. The most perfect terminal of the future will be the terminal of today. Leave it the heck alone. Terminal Emulators (1984 for MacTerminal), Vi (1976 by Bill Joy then 1988 by Bram Moolenaar for Vi IMproved) and Emacs (1976 by David A. Moon and Guy L. Steele Jr. then 1984 for GNU Emacs by Richard Stallman) are extremely primordial ancient programs. Among the oldest programs still in active use. There is a reason for that. During my evolution with technology, every time I wanted these programs to do something "familiar", it was because of my own ignorance and lack of familiarity. As I became familiar, I slowly realized that their power is in their simplicity. Not everything needs to be improved. "There is more to life than speeding it up" - Mahatma Gandhi
No, the problem is that the proposal is not enough *bold*.
A "barely better" version of something entrenched rarely win (maybe only if the old thing not get updaters).
This is the curse of OpenOffice < MS Office.
This is in fact the major reason:
> Great, now you just need to build and maintain shims for every tool in existence
MOST of that tools are very bad at ux! so inconsistent, weird, arcane that yes, is MADNESS to shim all of them.
Instead, if done from first principles, you can collapse thousands of cli arguments, options, switched and such things in few (btw a good example is jj vs git).
This is how could be: Adopt an algebra similar to the relational model, and a standardized set of most things millions of little tools have (like the commands help, sort, colors, input/output formats, etc) and then suddenly you have a more tractable solution.
ONLY when a tool is a total game changer people will switch.
And what about all the other stuff? In FoxPro (that in some ways show the idea you just preen `!` and then run the shell command you need. That is enough (editors and such? Much better to redo in the new way, and everyone knows that vim and emacs fan never change ways)
A "barely better" version of something entrenched rarely win (maybe only if the old thing not get updaters).
This is the curse of OpenOffice < MS Office.
This is in fact the major reason:
> Great, now you just need to build and maintain shims for every tool in existence
MOST of that tools are very bad at ux! so inconsistent, weird, arcane that yes, is MADNESS to shim all of them.
Instead, if done from first principles, you can collapse thousands of cli arguments, options, switched and such things in few (btw a good example is jj vs git).
This is how could be: Adopt an algebra similar to the relational model, and a standardized set of most things millions of little tools have (like the commands help, sort, colors, input/output formats, etc) and then suddenly you have a more tractable solution.
ONLY when a tool is a total game changer people will switch.
And what about all the other stuff? In FoxPro (that in some ways show the idea you just preen `!` and then run the shell command you need. That is enough (editors and such? Much better to redo in the new way, and everyone knows that vim and emacs fan never change ways)
I think this will be like the Fish shell, where backwards compatibility is left to existing tools, but a fresh environment is available going forward.
> Great, now you just need to build and maintain shims for every tool in existence, force your users to use your own custom tools that support these features, and ensure that everything interoperates smoothly.
Yes, this is the work. https://becca.ooo/blog/vertical-integration/
Yes, this is the work. https://becca.ooo/blog/vertical-integration/
Currently being discussed at https://news.ycombinator.com/item?id=45891772
> I'm not saying that this ecosystem couldn't be improved
Yes, you effectively are, and the current unstructured buggy mess is "just works" for you.
> But it needs broad community discussion, planning, and support,
Where was this when all the historic mistakes were made? And why would fixing them suddenly needs to overcome this extra barrier?
Yes, you effectively are, and the current unstructured buggy mess is "just works" for you.
> But it needs broad community discussion, planning, and support,
Where was this when all the historic mistakes were made? And why would fixing them suddenly needs to overcome this extra barrier?
Nonsense. It's just some person brainstorming improvements. You shouldn't need "broad community discussion" every time you toy with some ideas.
Two interesting projects in that space:
- https://arcan-fe.com/ which introduces a new protocol for TUI applications, which leads to better interactions across the different layers (hard to describe! but the website has nice videos and explanations of what is made possible)
- Shelter, a shell with reproducible operations and git-like branches of the filesystem https://patrick.sirref.org/shelter/index.xml
- https://arcan-fe.com/ which introduces a new protocol for TUI applications, which leads to better interactions across the different layers (hard to describe! but the website has nice videos and explanations of what is made possible)
- Shelter, a shell with reproducible operations and git-like branches of the filesystem https://patrick.sirref.org/shelter/index.xml
omg i've wanted something like shelter for literal years
it "cheats" a little because it requires the underlying filesystem to support snapshots but it's still really really cool, thank you for the link!
it "cheats" a little because it requires the underlying filesystem to support snapshots but it's still really really cool, thank you for the link!
I also have lots of ideas, not all that different from the goals of some of these... but there's something critical to remember. The terminal survives as it is, because so many tools were built to run on them. They are only becoming more cross platform and feature rich, albeit slowly and conservatively.
Maintaining a high level of backwards compatibility while improving the user experience is critical. Or at least to me. For example, my #1 fristration with neovim, is the change to ! not just swapping the alt screen back to the default and letting me see and run what I was doing outside of it.
We generally like the terminal because, unlike GUIs it's super easy to turn a workflow into a script, a manual process into an automated process. Everything is reproducible, and everything is ripgrep-able. It's all right there at your fingertips.
I fell in love with computers twice, once when I got my first one, and again when I learned to use the terminal.
Maintaining a high level of backwards compatibility while improving the user experience is critical. Or at least to me. For example, my #1 fristration with neovim, is the change to ! not just swapping the alt screen back to the default and letting me see and run what I was doing outside of it.
We generally like the terminal because, unlike GUIs it's super easy to turn a workflow into a script, a manual process into an automated process. Everything is reproducible, and everything is ripgrep-able. It's all right there at your fingertips.
I fell in love with computers twice, once when I got my first one, and again when I learned to use the terminal.
Any article about this topic that does not at least mention https://arcan-fe.com/about/ feels incomplete. (Also, Arcan is already available.)
whoa this looks fascinating, i've never heard of it before! thank you for the link :)
To add to lproven's point.
An article called "A Spreadsheet and a Debugger walk into a Shell" [0] by Bjorn (letoram) is a good showcase of an alternative to cells in a Jupyter notebook (Excel like cells!). Another alternative a bit more similar to Jupyter that also runs on Arcan is Pipeworld.
[0] https://arcan-fe.com/2024/09/16/a-spreadsheet-and-a-debugger... [1] https://arcan-fe.com/2021/04/12/introducing-pipeworld/
PS: I hang out at Arcan's Discord Server, you are welcome to join https://discord.com/invite/sdNzrgXMn7
An article called "A Spreadsheet and a Debugger walk into a Shell" [0] by Bjorn (letoram) is a good showcase of an alternative to cells in a Jupyter notebook (Excel like cells!). Another alternative a bit more similar to Jupyter that also runs on Arcan is Pipeworld.
[0] https://arcan-fe.com/2024/09/16/a-spreadsheet-and-a-debugger... [1] https://arcan-fe.com/2021/04/12/introducing-pipeworld/
PS: I hang out at Arcan's Discord Server, you are welcome to join https://discord.com/invite/sdNzrgXMn7
I was thinking of Arcan and the Lash#Cat9 setup by the end of your second paragraph. I'm very surprised you had not met it: it seems so directly aligned with your interests and goals, but all you seemed to talk about was Jupyter, a tool which I tried and TBH discarded after 10min.
It is very hard to explain Arcan but I tried:
https://www.theregister.com/2022/10/25/lashcat9_linux_ui/
I talked to Bjorn Stahl quite a bit before writing it, but he is so smart he seems to me to find it hard to talk down to mere mortals. There's a pretty good interview with him on Lobsters:
https://lobste.rs/s/w3zkxx/lobsters_interview_with_bjorn_sta...
You really should talk to him. Together you two could do amazing things. But IMHO let Jupyter go. There's a lot more to life than Python. :-)
It is very hard to explain Arcan but I tried:
https://www.theregister.com/2022/10/25/lashcat9_linux_ui/
I talked to Bjorn Stahl quite a bit before writing it, but he is so smart he seems to me to find it hard to talk down to mere mortals. There's a pretty good interview with him on Lobsters:
https://lobste.rs/s/w3zkxx/lobsters_interview_with_bjorn_sta...
You really should talk to him. Together you two could do amazing things. But IMHO let Jupyter go. There's a lot more to life than Python. :-)
Y'know, I spent a week investigating doing something similar with the Windows Terminal about 18 months ago: https://github.com/microsoft/terminal/issues/16495#issuecomm...
There's even more under the "Updates archive" expando in that post.
It was a pretty compelling prototype. But after I played with Polyglot Notebooks[1], I pretty much just abandoned that experiment. There's a _lot_ of UI that needs to be written to build a notebook-like experience. But the Polyglot notebooks took care of that by just converting the commandline backend to a jupyter kernel.
I've been writing more and more script-like experiments in those ever since. Just seems so much more natural to have a big-ol doc full of notes, that just so happens to also have play buttons to Do The Thing.
[1]: https://marketplace.visualstudio.com/items?itemName=ms-dotne...
There's even more under the "Updates archive" expando in that post.
It was a pretty compelling prototype. But after I played with Polyglot Notebooks[1], I pretty much just abandoned that experiment. There's a _lot_ of UI that needs to be written to build a notebook-like experience. But the Polyglot notebooks took care of that by just converting the commandline backend to a jupyter kernel.
I've been writing more and more script-like experiments in those ever since. Just seems so much more natural to have a big-ol doc full of notes, that just so happens to also have play buttons to Do The Thing.
[1]: https://marketplace.visualstudio.com/items?itemName=ms-dotne...
I hadn’t seen these yet but have been low-key looking for this for a while. I think something like a polyglot notebook might be a better “system” for a person or an LLM to manipulate to achieve something…
Actually a really neat concept with building that into windows terminal. I remember seeing this a while ago. Personally I love the notebook style interactive documents and hope there are more going forward.
I tried to find a terminal which can shows images, videos, and other media. I know it's not a UNIX way, but sometimes it can help. There are multiple options, but they didn't click in me.
But just showing a browser like Jupyter would be very useful. It can handle a wide variety of media, can easily show JS heavy webpages unlike curl, and with text option to show text based result like w3m but can handle JS, it will be more useful.
But just showing a browser like Jupyter would be very useful. It can handle a wide variety of media, can easily show JS heavy webpages unlike curl, and with text option to show text based result like w3m but can handle JS, it will be more useful.
browser google.com/maps # show google map and use interactively
browser google.com/search?q=cat&udm=2 # show google image result
browser --text jsheavy.com | grep -C 10 keyword # show content around keyword but can handle JS
vim =(browser --text news.ycombinator.com/item?id=45890186) # show Hacker News article and can edit text result directly)> terminal which can shows images, videos, and other media
That is typically not the job of terminals, but of programs. fbi, omxplayer, etc exist.
That is typically not the job of terminals, but of programs. fbi, omxplayer, etc exist.
But the terminal can provide capabilities that allow shell programs to do those things. See e.g. the Kitty graphics protocol: https://sw.kovidgoyal.net/kitty/graphics-protocol/
Yes.
> fbi, omxplayer, etc exist.
> fbi, omxplayer, etc exist.
This I am afraid does not feel as the right thing to do. I think the KISS-principle is a good standard to follow and while terminals have to do more than one thing, it should not do everything. Complexity leads to instability. Terminals has to be nimble and not clumsy behemoths like web browsers.
Terminals are far from simple, that's the whole problem. We carry the weight of decades of technical constraints and arbitrary decisions on our shoulders every time we fire up a terminal emulator.
My personal opinion-psuedoterminals should be enhanced to provide some mechanism for sending out-of-band data, like the existing TIOCPKT but on steroids. Maybe something like… if both ends support it, they can exchange JSON-RPC messages over this out-of-band channel, with it being possible to discover if the other side supports this or not. Possibly this is just a new TIOC* ioctl
Why? Well one reason is escape sequences are really limited and messy. This would enable everyone to gradually and backward-compatibly transition to a more modern alternative. Once you have a JSON-RPC channel, the two ends can use it to negotiate what specific features they support. It would be leveraging patterns already popular with LSP, MCP, etc. And it would be mostly in userspace, only a small kernel enhancement would be required (the kernel doesn’t have to actually understand these JSON-RPC messages just offer a side channel to convey them).
I suppose you could do it without any kernel change if you just put a Unix domain socket in an environment variable: but that would be more fragile, some process will end up with your pty but missing the environment variable or vice versa
Actually I’d add this out-of-band JSON-RPC feature to pipes too, so if I run “foo | bar”, foo and bar can potentially engage in content/feature negotiation with each other
Why? Well one reason is escape sequences are really limited and messy. This would enable everyone to gradually and backward-compatibly transition to a more modern alternative. Once you have a JSON-RPC channel, the two ends can use it to negotiate what specific features they support. It would be leveraging patterns already popular with LSP, MCP, etc. And it would be mostly in userspace, only a small kernel enhancement would be required (the kernel doesn’t have to actually understand these JSON-RPC messages just offer a side channel to convey them).
I suppose you could do it without any kernel change if you just put a Unix domain socket in an environment variable: but that would be more fragile, some process will end up with your pty but missing the environment variable or vice versa
Actually I’d add this out-of-band JSON-RPC feature to pipes too, so if I run “foo | bar”, foo and bar can potentially engage in content/feature negotiation with each other
I think the modern unix'y thing to do here is always send all messages intended for the user to stderr (regardless of whether they are actually errors), and always respond with machine-friendly JSON on stdout by default. AFAIK there's no downsides to this.. you can still have color on stderr, you can still draw sixel pictures or whatever. Meanwhile pipes and redirection still work as expected.
No need for content/feature negotiations.. machine readable just defaults to JSON unless there's a --format flag for something else. And if you add that on the generation-side of the pipe, you just need to remember to put it on the consumer-side.
No need for content/feature negotiations.. machine readable just defaults to JSON unless there's a --format flag for something else. And if you add that on the generation-side of the pipe, you just need to remember to put it on the consumer-side.
There are many downsides.
There are problems with using JSON for this; other formats would be better. JSON needs escaping, cannot effectively transfer binary data (other than encoding as hex or base64), cannot use character sets other than Unicode, etc. People think JSON is good, but it isn't.
Also, you might want to use less or other programs for the text output, which might be the primary output that you might also want to pipe to other programs, redirect to a file (or printer), etc. This text might be separate from the status messages (which would be sent to stderr; these status messages are not necessarily errors, although they might be). If you use --help deliberately then the help message is the primary message, not a status message.
(In a new operating system design it could be improved, but even then, JSON is not the format for this; a binary format would be better (possibly DER, or SDSER, which is a variant of DER that supports streaming, in a (in my opinion) better way than CER and BER does).)
(Another possibility might be to add another file descriptor for structured data, and then use an environment variable to indicate its presence. However, this just adds to the messiness of it a little bit, and requires a bit more work to use it with the standard command shells.)
There are problems with using JSON for this; other formats would be better. JSON needs escaping, cannot effectively transfer binary data (other than encoding as hex or base64), cannot use character sets other than Unicode, etc. People think JSON is good, but it isn't.
Also, you might want to use less or other programs for the text output, which might be the primary output that you might also want to pipe to other programs, redirect to a file (or printer), etc. This text might be separate from the status messages (which would be sent to stderr; these status messages are not necessarily errors, although they might be). If you use --help deliberately then the help message is the primary message, not a status message.
(In a new operating system design it could be improved, but even then, JSON is not the format for this; a binary format would be better (possibly DER, or SDSER, which is a variant of DER that supports streaming, in a (in my opinion) better way than CER and BER does).)
(Another possibility might be to add another file descriptor for structured data, and then use an environment variable to indicate its presence. However, this just adds to the messiness of it a little bit, and requires a bit more work to use it with the standard command shells.)
I guess I don't see those as big downsides because I don't think people usually want binary data or quoted strings back from a CLI command, nor do they want column oriented output, nor "user friendly" tables.
Answering --help with JSON is a good example, how bad is it really if the response is JSON? Well, using less works fine still and you can still grep if you want simple substring search. Wanting a section is probably more common, so maybe you'd "grep" for a subcommand with `jq .subcommand` or an option with `jq .subcommand.option`, and maybe get yourself a fancier, JSON-friendly version of less that handles escaped quotes and newlines. Tables and tab-or-space delimited output overflow char limits, force the command-generator to figure out character wrapping, and so on. Now you need a library to generate CLI help properly, but if you're going to have a library why not just spit JSON and decouple completely from display details to let the consumer handle it.
Structured output by default just makes sense for practically everything except `cat`. And while your markdown files or csv files might have quoted strings, looking at the raw files isn't something people really want from shells or editors.. they want something "rendered" in one way or another, for example with syntax highlighting.
Basically in 2025 neither humans nor machines benefit much from unstructured raw output. Almost any CLI that does this needs to be paired with a parser (like https://github.com/kellyjonbrazil/jc) and/or a renderer (like https://github.com/charmbracelet/glow). If no such pairing is available then it pushes many people to separately reinvent parsers badly. JSON's not perfect but (non-minified) it's human-readable enough to address the basic issues here without jumping all the way towards binary or (shudder) HTML
Answering --help with JSON is a good example, how bad is it really if the response is JSON? Well, using less works fine still and you can still grep if you want simple substring search. Wanting a section is probably more common, so maybe you'd "grep" for a subcommand with `jq .subcommand` or an option with `jq .subcommand.option`, and maybe get yourself a fancier, JSON-friendly version of less that handles escaped quotes and newlines. Tables and tab-or-space delimited output overflow char limits, force the command-generator to figure out character wrapping, and so on. Now you need a library to generate CLI help properly, but if you're going to have a library why not just spit JSON and decouple completely from display details to let the consumer handle it.
Structured output by default just makes sense for practically everything except `cat`. And while your markdown files or csv files might have quoted strings, looking at the raw files isn't something people really want from shells or editors.. they want something "rendered" in one way or another, for example with syntax highlighting.
Basically in 2025 neither humans nor machines benefit much from unstructured raw output. Almost any CLI that does this needs to be paired with a parser (like https://github.com/kellyjonbrazil/jc) and/or a renderer (like https://github.com/charmbracelet/glow). If no such pairing is available then it pushes many people to separately reinvent parsers badly. JSON's not perfect but (non-minified) it's human-readable enough to address the basic issues here without jumping all the way towards binary or (shudder) HTML
Structured output would be helpful in many ways, but JSON is not a good format for this (neither is YAML nor XML nor HTML).
> JSON's not perfect but (non-minified) it's human-readable enough to address the basic issues here without jumping all the way towards binary or (shudder) HTML
It does not address most of the real issues. Programs that deal with pictures, sounds, non-Unicode text, structures of the kinds that JSON does not have, etc, will not do as well; and the input/output will involve converting escaping. (One format that I think is better is DER, although, it is binary format. I did write a program to convert JSON to DER, though.)
> JSON's not perfect but (non-minified) it's human-readable enough to address the basic issues here without jumping all the way towards binary or (shudder) HTML
It does not address most of the real issues. Programs that deal with pictures, sounds, non-Unicode text, structures of the kinds that JSON does not have, etc, will not do as well; and the input/output will involve converting escaping. (One format that I think is better is DER, although, it is binary format. I did write a program to convert JSON to DER, though.)
For raw data type of applications, it's definitely important to be able to preserve pipeline oriented use-cases like `cat img.png | convert-stdin-to-jpg | convert-stdin-back-to-png | imgcat`. But in the hypothetical world where all CLI I/O moves towards JSON, I'd still argue this is not only possible but now strictly easier because you can just explicitly embed mimetype info + b64 instead of assuming/detecting encoding or requiring user to specify it, or working with heuristic file-magic. (Jupyter notebooks work like this to persist images instead of just flat text.) And presumably a smarter suite of JSON oriented tools like jcat/jless would either actually display that data, or notice the type and avoid spamming the screen with raw b64.
That can be helpful, although JSON is still a bad format for this, especially since now it requires base64 encoding. People think JSON is a good format but it isn't. (MIME is also not a very good format for identifying file formats, since you can only specify one format; although there is a "added on" specification like "+zip" and "+der" this isn't very good.)
I think standardizing a file descriptor interface would be ideal. It's ridiculous that the file descriptors are exposed and densely packed. I wonder if a protocol could be made that demultiplexes for stderr and the new file descriptor could be made.
I do not understand very well what you mean.
I'd like to make another standard file descriptor to manage the control plane, like stdin/stdout/stderr, but figuring out which file descriptor it should be is a bit complicated. I'm wondering if the OS could backwards-compatibly integrate it with stderr in the standard file descriptor at index 2.
Historically some systems did have more than three standard file descriptors - e.g. for MS-DOS C compilers, a de facto standard was stdprn was your printer and stdaux was a serial port - this was because while Unix by default starts each process with 3 inherited handles, MS-DOS has 5 (CP/M influence). NT-based Windows abandoned this
But trying to add a fourth now, would likely break too many things; some software will assume any fd > 2 is free for it to clobber.
The IBM mainframe operating system z/OS (formerly MVS), classically instead of numbers for inherited descriptors, the API uses names (DDNAMEs)-that would have made adding a new one a lot easier. But decades too late for that in Unix land, and eventually MVS added the Unix way too for Unix compatibility-the classic API still uses DDNAMEs, but many apps now use the file descriptor-based z/OS Unix API instead
But trying to add a fourth now, would likely break too many things; some software will assume any fd > 2 is free for it to clobber.
The IBM mainframe operating system z/OS (formerly MVS), classically instead of numbers for inherited descriptors, the API uses names (DDNAMEs)-that would have made adding a new one a lot easier. But decades too late for that in Unix land, and eventually MVS added the Unix way too for Unix compatibility-the classic API still uses DDNAMEs, but many apps now use the file descriptor-based z/OS Unix API instead
OK, but I don't know how you would integrate it with an existing file descriptor. (It is why I suggested using a environment variable to manage this.)
You can open another file descriptor at any time and some programs allow you to specify a file descriptor instead of the filename.
I think JSON would not be the good format for this; it is too limited and requires escaping. DER or SDSER might be a better format; numbers can be stored efficiently in binary, no escaping is needed, you can use any character set (not only Unicode), binary data can be stored directly (rather than needing to encode as hex or base64), etc.
If one were adding this to the kernel, maybe rather than stipulating a specific protocol, assign them magic numbers; maybe JSON-RPC could be protocol 0x4a534f4e. An app could ask the kernel “which protocols does the pty master support?”, and get back a list of integers. And then it could ask to open a sidechannel for protocol 0x4a534f4e. So the kernel doesn’t even have to get in the business of mandating a specific protocol (whether JSON-RPC or CBOR or 0MQ or whatever), it just opens side channels with a meaningless (to the kernel) integer to identify its protocol.
I think that might work OK.
Passing the process ID and user ID might be helpful to improve security of the terminal emulator, too. If the sidechannel is a UNIX socket then it will do this (with SCM_CREDENTIALS), as well as pass file descriptors (with SCM_RIGHTS).
Passing the process ID and user ID might be helpful to improve security of the terminal emulator, too. If the sidechannel is a UNIX socket then it will do this (with SCM_CREDENTIALS), as well as pass file descriptors (with SCM_RIGHTS).
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 (Read-Eval-Browse Loop) concept, where instead of the output being simply printed as text, it is treated as values that can be visualized and browsed using graphical viewers.
Existing editors can already cover the runbooks use case pretty well. Those can be just markdown files with key bindings to send code blocks to shell process for evaluation. It works great with instructions in markdown READMEs.
The main missing feature editor-centric command like workflow I can imagine is the history search. It could be interesting to see if it would be enough to add shell history as a completion source. Or perhaps have shell LSP server to provide history and other completions that could work across editors?
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 (Read-Eval-Browse Loop) concept, where instead of the output being simply printed as text, it is treated as values that can be visualized and browsed using graphical viewers.
Existing editors can already cover the runbooks use case pretty well. Those can be just markdown files with key bindings to send code blocks to shell process for evaluation. It works great with instructions in markdown READMEs.
The main missing feature editor-centric command like workflow I can imagine is the history search. It could be interesting to see if it would be enough to add shell history as a completion source. Or perhaps have shell LSP server to provide history and other completions that could work across editors?
> It could be interesting to see if it would be enough to add shell history as a completion source.
Atuin runbooks (mentioned in the article) do this! Pretty much anywhere we allow users to start typing a shell command we feed shell history into the editor
Atuin runbooks (mentioned in the article) do this! Pretty much anywhere we allow users to start typing a shell command we feed shell history into the editor
> It could be interesting to see if it would be enough to add shell history as a completion source.
Fish shell does this too
Fish shell does this too
I have tried to like Jupyter but I can’t.
My biggest gripe with it is that it quickly ends up becoming an actual production workload, and it is not simple to “deploy” and “run” it in an ops way.
Lots of local/project specific stuff like hardcoded machine paths from developers or implicit environments.
Yes, I know it can be done right, but it makes it sooooooooo easy to do it wrong.
I think I can’t not see it as some scratchpad for ad-hoc stuff.
My biggest gripe with it is that it quickly ends up becoming an actual production workload, and it is not simple to “deploy” and “run” it in an ops way.
Lots of local/project specific stuff like hardcoded machine paths from developers or implicit environments.
Yes, I know it can be done right, but it makes it sooooooooo easy to do it wrong.
I think I can’t not see it as some scratchpad for ad-hoc stuff.
Instead of reinventing terminals, what if we standardized on structured data exchange between CLI tools (like JSON/msgpack) and let terminal emulators render it intelligently? The backwards compatibility problem that nixpulvis mentions is real - any "terminal of the future" needs to run existing tools well first while gradually enabling richer experiences.
Shell tooling is as successful today in large part due to it's simple byte string/file based protocol. Adding structured data types to the shell and shell command pipelining would turn it from something with a good UI but meh for scripting to one that is good at scripting but meh for UI. Shells are primarily a UI and the focus should stay on that.
I really wish something like Mathematica is available in open source. It is a notebook environment based on a Lisp-like language.
Its flexibility is beyond imagination. Programs can emit anything from simple numbers/vectors/matrices to medias (image, sound, video, either loaded or generated) to interactive programs, all of which can be embedded into the notebook. You can also manipulate every input and output code blocks programmatically, because it's Lisp, and can even programmatically generate notebooks. It can also do typesetting and generate presentation/PDF/HTML from notebooks.
What people have been doing w/ Markdown and Jupyter in recent years has been available in Mathematica since (at least) 1-2 decades ago. FOSS solutions still fall short, because they rely on static languages (relative to Lisp, of course).
I mean, really, it's a technological marble. It's just that it's barred behind an high price tag and limited to low core counts.
Its flexibility is beyond imagination. Programs can emit anything from simple numbers/vectors/matrices to medias (image, sound, video, either loaded or generated) to interactive programs, all of which can be embedded into the notebook. You can also manipulate every input and output code blocks programmatically, because it's Lisp, and can even programmatically generate notebooks. It can also do typesetting and generate presentation/PDF/HTML from notebooks.
What people have been doing w/ Markdown and Jupyter in recent years has been available in Mathematica since (at least) 1-2 decades ago. FOSS solutions still fall short, because they rely on static languages (relative to Lisp, of course).
I mean, really, it's a technological marble. It's just that it's barred behind an high price tag and limited to low core counts.
I think what makes Mathematica so great product is that it is not open source (development is strongly guided by one man) and that it costs (can afford to hire many hundreds of people to build the professional design).
Have you tried mathics?
https://mathics.org
https://mathics.org
I appreciated the Pluto.jl mention! Going from Pluto notebooks that understand data flow to Jupyter notebooks where you have to tell the computer which order to run the cells in is always baffling to me. Why doesn't Jupyter know the run order and dependencies already? The way Pluto handles dependencies between code cells is really just so nice.
If you haven't yet do check out Marimo
[0] https://marimo.io/
[0] https://marimo.io/
> It does this using (mostly) standard features built-in to the terminal and shell (a custom DCS): you can read their explanation here. It's possible to do this less invasively using OSC 133 escape codes; I'm not sure why Warp didn't do this, but that's ok.
Independent of the rest, I would love for more terminal emulators to support OSC 133.
Independent of the rest, I would love for more terminal emulators to support OSC 133.
I had thought of a idea in a operating system design, which has many similarities to this but also many significant differences. The rest of the operating system would also be designed to support this, and the REPL would also be integrated with editors (like they show) and with a zoned spreadsheet. There would also be transactions (not the same as described there, but there is a similarity), and also capabilities (usable for security and many other things), and possibility to move objects between windows (this also allows it to work better with GUI; e.g. you can write a loop and use some combination of keys with mouse to drag a command button from a GUI window into your text in order to execute that command button within the loop; or you can copy data displayed in a table in another program in order to perform calculations on it or write a conversion to other format to then copy into another program, etc). However, tabs and panes would be handled by the window manager. However, it would use a binary format (a kind of TLV format), and it would not use CSS and HTML and Unicode. For rich text and other things there would also be a Reveal Codes function in order to reveal (and modify) the codes.
By the way, have you started writing your OS?
This might be useful (maybe) to the author: I am in a group (probably small, but I don’t think negligeble) that gave up on Warp because it doesn’t support standard or custom command completions [0]
Some lesson must surely be drawn from this about incremental adoption.
[0] https://github.com/warpdotdev/Warp/issues/1811
Some lesson must surely be drawn from this about incremental adoption.
[0] https://github.com/warpdotdev/Warp/issues/1811
yeah! so i somehow forgot to include this in the post, but one of the thing i would want as part of this is tab complete that integrates with the shell, essentially it would make an RPC call (in the step 3 sense). there’s things that work like this already today, they’re just extremely cursed ^^ but that’s never stopped me before. https://github.com/Aloxaf/fzf-tab?tab=readme-ov-file#differe...
I wish people would stop back-porting new features into vt terms, since those “features” gradually leak into terminal programs, which start spewing garbage in older terminals at the next update. Instead of having a standard, we get ESC[whatever-the-fuck-i-feel-like;, but with vt220 characteristics.
Missing out on inline images and megabytes of true-color CSI codes is a feature, not a bug, when bandwidth is limited.
If you want jupyter, we have jupyter. If you want HTML, we have several browsers. If you want something else, make it, but please don’t use vt220 codes and call it a terminal.
The article is just wish-listing more NIH barbarism to break things with. RedHat would hire this guy in a heartbeat.
Missing out on inline images and megabytes of true-color CSI codes is a feature, not a bug, when bandwidth is limited.
If you want jupyter, we have jupyter. If you want HTML, we have several browsers. If you want something else, make it, but please don’t use vt220 codes and call it a terminal.
The article is just wish-listing more NIH barbarism to break things with. RedHat would hire this guy in a heartbeat.
AMEN Brother.
It's especially important for retro and embeded computing. Legacy systems as well (banks, telecoms etc)
That's why most teleco hardware still runs telnet client haha (RRUS AND BBUS) (over IPsec) hehe
It's especially important for retro and embeded computing. Legacy systems as well (banks, telecoms etc)
That's why most teleco hardware still runs telnet client haha (RRUS AND BBUS) (over IPsec) hehe
Effectively you have to use tmux or screen as a condom at that point - programs that refuse to use terminfo/termcap will spew whatever xterm-like escapes they hardcode at tmux/screen, which then uses terminfo/termcap to translate to your actual terminal.
[deleted]
Re "stage 2: persistent sessions", iTerm2 already does this. The PTYs are owned by background processes independent of the GUI application. So iTerm2 can upgrade the application without interrupting the running terminal sessions.
this is really cool omg! i didn't know that, i'll do some research.
one of the strange things to me about the terminal landscape is how little knowledge sharing there is compared to other domains i'm familiar with. iTerm has a bunch of things no one else has; kitty influenced wezterm but otherwise no one else seems to have valued reflection; there's a whole bunch of extensions to ANSI escapes but most of them are non-standard and mutually incompatible. it's weird. if i compare to something like build systems, there's a lot more cross-pollination of ideas there.
one of the strange things to me about the terminal landscape is how little knowledge sharing there is compared to other domains i'm familiar with. iTerm has a bunch of things no one else has; kitty influenced wezterm but otherwise no one else seems to have valued reflection; there's a whole bunch of extensions to ANSI escapes but most of them are non-standard and mutually incompatible. it's weird. if i compare to something like build systems, there's a lot more cross-pollination of ideas there.
You do make a good point there. There's a tonne of insular parochialism: "my tool is the best tool and I will loftily ignore the others."
This is why I wrote this:
https://www.theregister.com/2025/06/24/tiling_multiplexers_s...
Trying to bring a bunch of related tools together in one place and compare and contrast them.
This is why I wrote this:
https://www.theregister.com/2025/06/24/tiling_multiplexers_s...
Trying to bring a bunch of related tools together in one place and compare and contrast them.
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.wikipedia.org/wiki/Twin_(windowing_system)
It runs on lots more OSes than just Linux.
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.wikipedia.org/wiki/Twin_(windowing_system)
It runs on lots more OSes than just Linux.
I ment programs that implement persistent (shell) sessions.
I'll cop to not reading the whole list before commenting, but I skimmed this and didn't really notice anything about speed or performance.
When using tools that can emit 0 to millions of lines of output, performance seems like table-stakes for a professional tool.
I'm happy to see people experiment with the form, but to be fit for purpose I suspect the features a shell or terminal can support should work backwards from benchmarks and human testing to understand how much headroom they have on the kind of hardware they'd like to support and which features fit inside it.
When using tools that can emit 0 to millions of lines of output, performance seems like table-stakes for a professional tool.
I'm happy to see people experiment with the form, but to be fit for purpose I suspect the features a shell or terminal can support should work backwards from benchmarks and human testing to understand how much headroom they have on the kind of hardware they'd like to support and which features fit inside it.
Make the terminal very simple and easy to understand.
Rid us of the text-only terminal baggage that we deal with today. Even graphics are encoded as text, sent to the terminal, then decoded and dealt with.
Plan9 had the terminal right. It wasn't really a terminal, it was just a window which had a text prompt by default. It could run (and display!) graphical applications just as easily as textual applications.
If you want a terminal of the future, stop embracing terminals of the past.
Rid us of the text-only terminal baggage that we deal with today. Even graphics are encoded as text, sent to the terminal, then decoded and dealt with.
Plan9 had the terminal right. It wasn't really a terminal, it was just a window which had a text prompt by default. It could run (and display!) graphical applications just as easily as textual applications.
If you want a terminal of the future, stop embracing terminals of the past.
The discussion is about the terminal as an interface rather the emulator/renderer specifically, or in this case the windowing system. So in Plan 9 you could've a GUI app overtake the root window but could you have graphics intertwined with text when working at the shell?
> could you have graphics intertwined with text when working at the shell?
I don't know, but I assume so. Also I can't think of a use case for this but that's just my lack of imagination, I suspect.
I don't know, but I assume so. Also I can't think of a use case for this but that's just my lack of imagination, I suspect.
interesting post! shell integration has gotten a lot better since the new ConPTY on windows doesn’t strip OSC sequences & send them ahead of the text
A few years ago I worked on TopShell, an attempt to reimagine the shell+terminal using functional programming:
https://github.com/topshell-language/topshell#readme
It ticks some of the boxes, but tonnes of work would be needed to turn it into a full alternative.
It ticks some of the boxes, but tonnes of work would be needed to turn it into a full alternative.
"stage 1: transactional semantics" sounds like pure nonsense. How can a terminal have transactions if the OS does not have them?
The terminal of the future is called a web browser.
It could have been. The platform got taken over by a very different culture and has tended to serve different purposes.
The web solves problems that are almost impossible to properly solve with a terminal, particularly with rendering of more complicated languages and display and interaction with sophisticated visualisations.
Pushing the terminal further while maintaining compatibility, performance and avoiding a terminal war with incompatible protocols is going to be a struggle.
The web solves problems that are almost impossible to properly solve with a terminal, particularly with rendering of more complicated languages and display and interaction with sophisticated visualisations.
Pushing the terminal further while maintaining compatibility, performance and avoiding a terminal war with incompatible protocols is going to be a struggle.
pushing the terminal further while maintaining compatibility, performance and avoiding a terminal war with incompatible protocols is going to be a struggle.
Unless someone creates a cross-platform, open source, modern and standards compliant terminal engine [1].
[1]: https://mitchellh.com/writing/libghostty-is-coming
Unless someone creates a cross-platform, open source, modern and standards compliant terminal engine [1].
[1]: https://mitchellh.com/writing/libghostty-is-coming
Yes, this was my first thought too. I haven't used a hardware text terminal since the 80s so maybe I don't get where the TFA is coming from? It starts out by stating "This post is part 6 of a multi-part series called 'the computer of the next 200 years'". Given that context, why is the focus on the evolution of 1980s VT100-type protocols?
I'm at home and there are over a half dozen different devices within 25 ft which come standard with an HTML browser. Sure, modern browsers have some incompatibilities at the edges but if you're in need of a multi-decade, platform agnostic, lingua franca then W3C minimal baseline HTML/CSS + ECMAscript seems like the obvious winner (with no viable second place really).
Don't get me wrong, I'd be quite interested in a vintage computing discussion on the evolution of VT-100/220 etc terminal protocols. There were some interesting things done into the 90s. That's actually what I clicked in expecting. Of course, those were all supplanted by either XWindows (which I never got to use much) or eventually HTML/CSS. And if we're talking more broadly about structured page description languages, there's no shortage of alternatives from NAPLPS to Display Postscript.
Don't get me wrong, I'd be quite interested in a vintage computing discussion on the evolution of VT-100/220 etc terminal protocols. There were some interesting things done into the 90s. That's actually what I clicked in expecting. Of course, those were all supplanted by either XWindows (which I never got to use much) or eventually HTML/CSS. And if we're talking more broadly about structured page description languages, there's no shortage of alternatives from NAPLPS to Display Postscript.
I don’t know how you work, but I spend a good portion of my day in a terminal while working on AI-type projects.
The terminal never left.
The terminal never left.
I'd like to make the distinction between text, indeed, word/command based interfaces and "terminal".
It so happens that right now one is synonymous with the other but there's no instrinsic requirement.
There's probably something to be said for the inherent constraints imposed by the terminal protocol, but, again, we can build the same things without that.
It so happens that right now one is synonymous with the other but there's no instrinsic requirement.
There's probably something to be said for the inherent constraints imposed by the terminal protocol, but, again, we can build the same things without that.
That would be quite an own goal, to invite an extra middleman into the mix. Especially when so many people will go the path of least resistance and use a tech giant product as that middleman.
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.
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 onerous. I implemented such a parser myself in probably a few hundred lines of code, plus a bit more to do all of the rendering (drawing glyphs directly to a bitmapped display, with no libraries) and handling user input from a keyboard. You'd have a difficult time properly parsing and rendering a significant subset of HTML in less than a few _thousand_ lines of code.
Edit to add: terminal emulators often implement other terminals like VT420, but the VT220 is enough for the vast majority of terminal needs.
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 onerous. I implemented such a parser myself in probably a few hundred lines of code, plus a bit more to do all of the rendering (drawing glyphs directly to a bitmapped display, with no libraries) and handling user input from a keyboard. You'd have a difficult time properly parsing and rendering a significant subset of HTML in less than a few _thousand_ lines of code.
Edit to add: terminal emulators often implement other terminals like VT420, but the VT220 is enough for the vast majority of terminal needs.
I haven't personally implemented one but I'll quote someone who has spent a lot more time on it:
> Many of these implementations are ad-hoc, one-off solutions. They aren't using any shared library or codebase.2 Terminal emulation is a classic problem that appears simple on the surface but is riddled with unexpected complexities and edge cases.3 As a result, most of these implementations are incomplete, buggy, and slow.4 [1]
(I mean, it's possible html/css deserves to be called horrible also but they produce an undeniably superior result)
[1] https://mitchellh.com/writing/libghostty-is-coming
> Many of these implementations are ad-hoc, one-off solutions. They aren't using any shared library or codebase.2 Terminal emulation is a classic problem that appears simple on the surface but is riddled with unexpected complexities and edge cases.3 As a result, most of these implementations are incomplete, buggy, and slow.4 [1]
(I mean, it's possible html/css deserves to be called horrible also but they produce an undeniably superior result)
[1] https://mitchellh.com/writing/libghostty-is-coming
> 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?
Does it cover Tek and ReGIS? Where can I find it?
https://vt100.net/emu/dec_ansi_parser
VT500 should include ReGIS
VT500 should include ReGIS
I think the 400 and 500 didn’t have any bit-mapped graphics.
Everything they're asking for my head was just screaming the whole time "this is a web browser".
Before that there were screen oriented terminals, of which the 3270 is still in use.
opened on the chatgpt page
I'm surprised there's no mention of fzf. fzf has greatly improved my terminal experience and I tend to incorporate it into almost every script that has any interactivity. I think any terminal of the future could incorporate fuzzy finding much better.
lots of terminals these days support imgcat and i rely on it heavily: https://iterm2.com/documentation-images.html
We don't need transactions and Jupyter style. Just separate representation from underlying state (a simplified dom), and migrate from IO streams model to object streams model.
I always thought that a terminal should look and behave much like a Mathematica notebook. Imagine my disappointment when I saw my first Unix shell.
Y'all, just give me a terminal that strongly and fully integrates with a file manager. Dolphin is almost, but not quite, this.
I expected this to be about some "AI first" terminal. But the article doesn't mention AI at all, for better or worse...
For better, my friend
Wait. Did Jyn just describe Emacs?
you could build an emacs frontend for this model! the thing i am trying to describe is “getting out of the box”. imagine a terminal session that is shared between emacs, iTerm, and a mobile phone ssh’d in over the network, that’s my vision.
I think that's possible with: well, ssh and emacs.
My terminal is the only user-friendly way to interact with a variety of system resources on linux (generally, implicitly because of the filesystem API). I don't go to view where named pipes are in vscode, I go to the terminal and understand the problem structure there, especially when autogenerated pipelines come into the mix. If I need to look at daemons or tune perf, I also reach for the terminal.
Any solution has to address this use case first, IMO. There are some design constraints here, like:
- I don't care about video game levels of graphics - I generally want things to feel local, as opposed to say some cloud GUI - byte stream model: probably bad? But how would I do better?
as just a few examples I thought of in 10 seconds; there's probably way more.
I've thought about the author's exact complaints for months, as an avid tmux/neovim user, but the ability to interact with system primitives on a machine that I own and understand is important.
But hey, those statements are design constraints too - modern machines are tied somewhat to unix, but not really. Sysadmin stuff? Got standardized into things like systemd, so maybe it's a bit easier.
So it's not just a cynical mess of "everything is shit, so let's stick to terminals!" but I'd like to see more of actually considering the underlying systems you are operating on, fundamentally, rather than immidiately jumping to sort of, "how do we design the best terminal" (effectively UI)? The actual workflow of being a systems plumber happens to be aided very well by tmux and vim :)
(And to be fair, I only make this critique because I had this vague feeling for a while about this design space, but couldn't formalize it until I read this article).
Any solution has to address this use case first, IMO. There are some design constraints here, like:
- I don't care about video game levels of graphics - I generally want things to feel local, as opposed to say some cloud GUI - byte stream model: probably bad? But how would I do better?
as just a few examples I thought of in 10 seconds; there's probably way more.
I've thought about the author's exact complaints for months, as an avid tmux/neovim user, but the ability to interact with system primitives on a machine that I own and understand is important.
But hey, those statements are design constraints too - modern machines are tied somewhat to unix, but not really. Sysadmin stuff? Got standardized into things like systemd, so maybe it's a bit easier.
So it's not just a cynical mess of "everything is shit, so let's stick to terminals!" but I'd like to see more of actually considering the underlying systems you are operating on, fundamentally, rather than immidiately jumping to sort of, "how do we design the best terminal" (effectively UI)? The actual workflow of being a systems plumber happens to be aided very well by tmux and vim :)
(And to be fair, I only make this critique because I had this vague feeling for a while about this design space, but couldn't formalize it until I read this article).
Why restrict it to Shell programs with script language? What about LLM powered chat? Terminal is the UI between humans and machines, future is IM App. What people do to each other, people and machines will do the same(ask,talk,chat,assign task).
one of the things that kinda petered out but was really interesting was xiki, kinda a precursor to some of this stuff.
[deleted]
the terminal of the future is here and it's https://github.com/ghostty-org/ghostty
It's not even CUA compliant. It's like one of those broken GNOME 40 tools, for people who don't know how to drive their computer with their keyboard.
Ghostty may be great performance/standards-wise but, currently at least, brings no innovations.
What do you mean by “terminal”? Perhaps you are referring to something like a VT100.
https://commons.wikimedia.org/wiki/File:DEC_VT100_terminal.j...
I may disappoint you with the fact that IBM PC-compatible computers have replaced devices of that class. We can only observe certain terminal emulators in some operating systems. There have been many attempts to expand the functionality of these emulators. However, most features beyond the capabilities of VT100 have not caught on (except UTF-8 support). I do not believe that anything will change in the foreseeable future.
https://commons.wikimedia.org/wiki/File:DEC_VT100_terminal.j...
I may disappoint you with the fact that IBM PC-compatible computers have replaced devices of that class. We can only observe certain terminal emulators in some operating systems. There have been many attempts to expand the functionality of these emulators. However, most features beyond the capabilities of VT100 have not caught on (except UTF-8 support). I do not believe that anything will change in the foreseeable future.
Yeah, sorry, but if the user friendly alternative to the VT100 emulators is anything like Jupyter, then I'll happily keep using alacritty, konsole and xterm, thanks.
I designed this months ago and 10x more but I’m going to release it in a bundle
A terminal will be useful for about twenty more years, not 200. At that point AI agents will take care of low level monkey wrenching for us. It’s like talking about designing a slide rule for the next 200 years.
Got some news for you, there will be unix and cobol still running in 20 years from now. No amount of AI will be able to convince bank executives the risk conversion is worth it.
Whatever merit alternatives have, the reality is these make long, like very long migration arcs, these days you will have so much team churn, maintenance rabit holes and regular tech debt and feature requests that its fair enough to say any project that starts to move out of Mainframe tech will never see the finishing line.
You are better off maintaining what already works. Either way why do you want to migrate when things are just working fine as is?
You are better off maintaining what already works. Either way why do you want to migrate when things are just working fine as is?
And a lot of that COBOL will still be managed with ISPF over 3270 terminal connections.
Calculators replaced slide rules because they are predictable and reliable tools. LLM agents will never be that simply by the nature of how they work.
I am sure we'll have something better in 200 years.
- Emacs (inherited from lisp machines?). A VM which is powered by lisp. The latter make it easy to redefine function, and commands are just annotated functions. As for output, we have the buffer, which can be displayed in windows, which are arranged in a tiling manner in a frame. And you can have several frames. As the buffer in a window as the same grid like basis as the terminal emulator, we can use cli as is, including like a terminal emulator (vterm, eat, ansi-term,...). You can eschew the terminal flow and use the REPL flow instead (shell-mode, eshell,...). There's support for graphics, but not a full 2d context.
- Acme: Kinda similar to emacs, but the whole thing is mostly about interactive text. Meaning any text can be a command. We also have the tiling/and stacking windows things that displays those texts.
I would add Smalltalk to that, but it's more of an IDE than a full computing environment. But to extend it to the latter would still be a lower effort than what is described in the article.