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, auth…
Self-plug since you're my exact target audience: check out Terminal Click [0]. It's still early days though.
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.
Let's replace it with something useful then, junk isn't the only option
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.…
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
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, auth…
> 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 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…
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 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'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?
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…
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…
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 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…
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 th…
As a non Emacs user, I would be really interested in a full writeup of how this works.
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…
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'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.
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.)