The terminal of the future
jyn.dev
The terminal of the future
1–10 of 174 posts
Re: The terminal of the future
#2The terminal of the future is called a web browser.
Re: The terminal of the future
#3The terminal of the future is called a web browser.
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.
Re: The terminal of the future
#4The terminal of the future is called a web browser.
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.
Re: The terminal of the future
#5The 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.
Re: The terminal of the future
#6This 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.
Re: The terminal of the future
#7The terminal of the future is called a web browser.
opened on the chatgpt page
Re: The terminal of the future
#8Y'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...
Re: The terminal of the future
#9This 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.
Re: The terminal of the future
#10This 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
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...