[HN Gopher] The terminal of the future
___________________________________________________________________
The terminal of the future
Author : miguelraz
Score : 61 points
Date : 2025-11-11 20:11 UTC (2 hours ago)
(HTM) web link (jyn.dev)
(TXT) w3m dump (jyn.dev)
| wredcoll wrote:
| The terminal of the future is called a web browser.
| add-sub-mul-div wrote:
| 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.
| wredcoll wrote:
| 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.
| shirro wrote:
| 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.
| hastamelo wrote:
| opened on the chatgpt page
| xixixao wrote:
| 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
| jynelson wrote:
| 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...
| zadjii wrote:
| 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...
| shellkr wrote:
| 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.
| Etheryte wrote:
| 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.
| zazaulola wrote:
| 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.
| cpendery wrote:
| 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
| skydhash wrote:
| I read the whole thing and at first glance, it seems like a whole
| NIH list of wishes. We already have alternatives to the terminal,
| but the article have no mentions of them:
|
| - 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.
| jynelson wrote:
| 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.
| thatcherc wrote:
| 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.
| walterlw wrote:
| If you haven't yet do check out Marimo
|
| [0] https://marimo.io/
| wrs wrote:
| 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.
| jynelson wrote:
| 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.
___________________________________________________________________
(page generated 2025-11-11 23:00 UTC)