Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The terminal of the future

jyn.dev

Post reply on HN
Print view View original

41–50 of 174 posts

Re: The terminal of the future

#41

Post by zzo38computer »

skissane wrote: post #40
zzo38computer wrote: post #38

Earlier quoted context omitted.

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 p…

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

Re: The terminal of the future

#43

Post by nixpulvis »

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.

Re: The terminal of the future

#44

Post by epage »

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

Re: The terminal of the future

#45

Post by jynelson »

art-w wrote: post #31

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

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!

Re: The terminal of the future

#46

Post by robot-wrangler »

skissane wrote: post #36

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 sequen…

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.

Re: The terminal of the future

#47

Post by alwillis »

shirro wrote: post #5
wredcoll wrote: post #2

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 term…

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

Re: The terminal of the future

#48

Post by stevenjgarner »

imiric wrote: post #27

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 t…

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

Re: The terminal of the future

#49

Post by krautburglar »

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.

Re: The terminal of the future

#50

Post by robot-wrangler »

skydhash wrote: post #13

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 arran…

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

Post reply on HN