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

101–110 of 174 posts

Re: The terminal of the future

#101

Post by medstrom »

slickytail wrote: post #88
spudlyo wrote: post #32

Earlier quoted context omitted.

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.

There's kinda not much to it. It's just that you have:

1. a full-fledged programming language

2. no namespacing (nothing is private)

3. no modern GUI concepts to take into account (no CSS `flex-direction`...)

4. no edit-compile-run cycle

5. people have written extensions for many decades

6. people always write extensions with the possibility in mind that their extensions may be extended

Then you can probably see how it works, with just your imagination!

Of course there's a number of epiphanies that may be needed... Like how the principle "compose many small Unix programs with text as the universal interface" is just like "compose many functions with return values as the universal interface", or that it isn't an editor and more like a terminal (with integrated tmux-like functionality) that you decided to turn into an editor, or that an editor waiting for text entry is just stuck in a `while`-loop of reading the next input character, what even is a shell, what even is a computer, etc etc.

Re: The terminal of the future

#102

Post by gsinclair »

abnercoimbre wrote: post #81
efitz wrote: post #74

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. [0] https://terminal.click

I looked at that link but didn’t understand what I was looking at and didn’t see a link that would give me an overview. I’d like to know more about it.

Re: The terminal of the future

#103

Post by brabel »

skydhash wrote: post #70
robot-wrangler wrote: post #66

Earlier quoted context omitted.

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…

I think we went past each other at some point. I was not arguing that you can use Emacs as a terminal emulator. I was talking more about terminals and shell being a way of computing. Emacs is an alternate way of computing. With terminals, you have the escapes sequences, the alternate screen, the shell capabilities. With Emacs, you have a lisp VM with a huge library of functions and buffers. I still use a normal termi…

I agree with you, once you have a terminal emulator like the one described in the post you are close to reinventing eMacs. Many have tried over the years, no one succeeded so far.

Re: The terminal of the future

#104

Post by abnercoimbre »

gsinclair wrote: post #102
abnercoimbre wrote: post #81

Earlier quoted context omitted.

Self-plug since you're my exact target audience: check out Terminal Click [0]. It's still early days though. [0] https://terminal.click

I looked at that link but didn’t understand what I was looking at and didn’t see a link that would give me an overview. I’d like to know more about it.

For sure, it's high on my TODO list to overhaul the site over Thanksgiving. If you scroll down a bit and play the 3-minute trailer you'll get the gist of it - pardon the inconvenience!

Re: The terminal of the future

#105

Post by Antibabelic »

7e wrote: post #69

A terminal will be useful for about twenty more years, not 200. At that point AI agents will take care of low level monkey wrenching for us. It’s like talking about designing a slide rule for the next 200 years.

Calculators replaced slide rules because they are predictable and reliable tools. LLM agents will never be that simply by the nature of how they work.

Re: The terminal of the future

#106

Post by kragen »

medstrom wrote: post #101
slickytail wrote: post #88

Earlier quoted context omitted.

As a non Emacs user, I would be really interested in a full writeup of how this works.

There's kinda not much to it. It's just that you have: 1. a full-fledged programming language 2. no namespacing (nothing is private) 3. no modern GUI concepts to take into account (no CSS `flex-direction`...) 4. no edit-compile-run cycle 5. people have written extensions for many decades 6. people always write extensions with the possibility in mind that their extensions may be extended Then you can probably see how…

Yes, but what keystrokes and which packages are you using? Elpa versions or a fork from elsewhere?

Re: The terminal of the future

#107

Post by 1718627440 »

hamasho wrote: post #34

I tried to find a terminal which can shows images, videos, and other media. I know it's not a UNIX way, but sometimes it can help. There are multiple options, but they didn't click in me. But just showing a browser like Jupyter would be very useful. It can handle a wide variety of media, can easily show JS heavy webpages unlike curl, and with text option to show text based result like w3m but can handle JS, it will b…

> terminal which can shows images, videos, and other media

That is typically not the job of terminals, but of programs. fbi, omxplayer, etc exist.

Re: The terminal of the future

#108

Post by jcgl »

efitz wrote: post #74

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…

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

Entirely agree. Stdio text (which is really just stdio bytes) deeply limits how composable your shell programs can be, since data and its representation are tightly coupled (they're exactly the same). I wrote a smidgin here[0] on my blog, but take a look at this unix vs. PowerShell example I have there. Please look beyond PowerShell's incidental verbosity here and focus more deeply on the profoundly superior composition that you can only have once you get self-describing objects over stdio instead of plain bytes.

  $ # the unix way
  $ find . -name '*.go' -not -name '*_test.go' -ctime -4 -exec cat {} \; | wc -l
  7119
  $ # the powershell way
  $ pwsh -c 'gci -recurse | where {($_.name -like "*.go") -and ($_.name -notlike "*_test.go") -and ($_.LastWriteTime -gt (get-date).AddDays(-4))} | gc | measure | select -ExpandProperty count'
  7119
[0] https://www.cgl.sh/blog/posts/sh.html

Re: The terminal of the future

#109

Post by 1718627440 »

vacuity wrote: post #78
zzo38computer wrote: post #72

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

You can open another file descriptor at any time and some programs allow you to specify a file descriptor instead of the filename.

Re: The terminal of the future

#110

Post by jcgl »

1718627440 wrote: post #107
hamasho wrote: post #34

I tried to find a terminal which can shows images, videos, and other media. I know it's not a UNIX way, but sometimes it can help. There are multiple options, but they didn't click in me. But just showing a browser like Jupyter would be very useful. It can handle a wide variety of media, can easily show JS heavy webpages unlike curl, and with text option to show text based result like w3m but can handle JS, it will b…

> terminal which can shows images, videos, and other media That is typically not the job of terminals, but of programs. fbi, omxplayer, etc exist.

But the terminal can provide capabilities that allow shell programs to do those things. See e.g. the Kitty graphics protocol: https://sw.kovidgoyal.net/kitty/graphics-protocol/
Post reply on HN