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.
The terminal of the future
91–100 of 174 posts
Re: The terminal of the future
#92the terminal of the future is here and it's https://github.com/ghostty-org/ghostty
Re: The terminal of the future
#93Earlier quoted context omitted.
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.
I am all for removing old junk but not that it should be replaced with newer junk.
Yeah... I have no wish to use a terminal with graphics modes.
Re: The terminal of the future
#94Earlier quoted context omitted.
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
Re: The terminal of the future
#95Wait. Did Jyn just describe Emacs?
Re: The terminal of the future
#96Y'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…
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…
Re: The terminal of the future
#97Wait. 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.
Re: The terminal of the future
#98I'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.
Re: The terminal of the future
#99Earlier quoted context omitted.
> 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 al…
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 argu…
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.)
Re: The terminal of the future
#100Why does the successor to the terminal need to be text oriented at all? Maybe it is an API. Maybe the kernel implements this API and it can be called locally or remotely. Maybe someone invents an OAuth translation layer to UIDs. The API allows syscalls or process invocation. Output is returned in response payload (ofc we have a stream shape too). Maybe in the future your “terminal” is an app that wraps this API, auth…
> Heresy warning. Maybe the inputs and outputs don’t look anything like CLI or stdio text. Maybe we move on from 1000-different DSLs (each CLI’s unique input parameters and output formats) and make inputs and outputs object shaped. Maybe we make the available set of objects, methods and schemas discoverable in the terminal API. This is Powershell. It’s a cool idea for sure. One thing I’ve noticed though is that it be…
> 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.