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

151–160 of 174 posts

Re: The terminal of the future

#151

Post by wpm »

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

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

> Speaking of copy/paste, that should work too, and ctrl-e, and ctrl-a, etc, etc.

readline in bash and zle in zsh both default to the standard emacs bindings so you're covered there.

The emacs bindings also work in every Cocoa NSTextField on macOS.

As far as having to go and download and configure all of those, 1., you don't need to do any of that, and you certainly wouldn't need to do it all at the same time. Configuring one of those a month when you come across needing one, and you find something in the default config you don't like, is definitely doable. 2. Once you do figure out your configs, they end up in your init.el. emacs is preinstalled on macOS and a quick $pkgmanager installed emacs away on Linux. Beyond that you can ship your entire setup just by downloading your emacs.d directory or init.el.

The same goes for basically any text editor, modern or not.

Re: The terminal of the future

#152

Post by [deleted] »

rbanffy wrote: post #126
jcgl wrote: post #108

Earlier quoted context omitted.

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

I have a distaste for the verboseness of PowerShell, but I also have concerns with the attempt to bake in complex objects into the pipeline. When you do that, programs up and down the stream need to be aware of that - and that makes it brittle. One key aspect of the Unix way is that the stream is of bytes (often interpreted as characters) with little to no hint as to what's inside it. This way, tools like `grep` and…

[deleted]

Re: The terminal of the future

#153

Post by LeicaLatte »

Instead of reinventing terminals, what if we standardized on structured data exchange between CLI tools (like JSON/msgpack) and let terminal emulators render it intelligently? The backwards compatibility problem that nixpulvis mentions is real - any "terminal of the future" needs to run existing tools well first while gradually enabling richer experiences.

Re: The terminal of the future

#154

Post by alfiedotwtf »

skeezyjefferson wrote: post #136
spudlyo wrote: post #122

Earlier quoted context omitted.

Many HN readers grok software development, would likely get a kick out of learning Emacs Lisp, and have time to invest in coding and debugging. Emacs is not as clumsy or random as modern user-hostile software -- it's an elegant tool for a more civilized age, and as such is not for everyone.

> Many HN readers grok software development, would likely get a kick out of learning Emacs Lisp, and have time to invest in coding and debugging. but why would they? what problems are they solving by being able to paste text into your web browsers address bar? or load a pdf into an LLM? or some other incredibly specific-to-you ability youve added? if simply adding a lisp interpreter to a program is enough to impress…

“What is the point of a paint brush? Sure, an artist picks it up and paints a masterpiece, but I see no utility in that because when I pick it up, all I can paint are squiggly lines. Paint brushes are useless!”

Re: The terminal of the future

#155

Post by alfiedotwtf »

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

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

> To successfully argue that it's just perfect as a terminal emulator, I think you need to find a way to ship it in exactly that configuration.

As you know, Emacs is more of a super environment that’s personally customised to a single individual. It wouldn’t make sense to hand over a fitted suit to someone else who is twice your size of you and then say “put it on, it looks good on me”.

Re: The terminal of the future

#156

Post by spudlyo »

skeezyjefferson wrote: post #136
spudlyo wrote: post #122

Earlier quoted context omitted.

Many HN readers grok software development, would likely get a kick out of learning Emacs Lisp, and have time to invest in coding and debugging. Emacs is not as clumsy or random as modern user-hostile software -- it's an elegant tool for a more civilized age, and as such is not for everyone.

> Many HN readers grok software development, would likely get a kick out of learning Emacs Lisp, and have time to invest in coding and debugging. but why would they? what problems are they solving by being able to paste text into your web browsers address bar? or load a pdf into an LLM? or some other incredibly specific-to-you ability youve added? if simply adding a lisp interpreter to a program is enough to impress…

> what problems are they solving

For me, it's about making a repeated workflow efficient. Sure, I could alt+tab over to my PDF viewer, figure out the range of pages I want, then switch to my terminal window, run qpdf with the right arguments to split the PDF into chunks, alt+tab over to my web browser, log into Google's AI studio, mouse over add context to the LLM, navigate a file-open dialog to find my PDF, paste in my OCR prompt, have Gemini spit out my text, press download, navigate another file-open dialog, and then open the resulting file in my editor of choice.

Instead I can open my PDF, press a few keys, and have the whole process done for me without having to think too much about it and get back to wondering if this damn verb should be in the continual/habitual, completed, or more than completed past.

> why not add it to something other than 1970s terminal text editor?

We're responding to an article entitled "The terminal of the future", and even the GUI version of Emacs is still very much rooted in the paradigm of the terminal but with some very nice improvements. I'm arguing that much of the future this article pines for is already here.

Re: The terminal of the future

#157

Post by wpm »

rbanffy wrote: post #130
unixplumber wrote: post #21

Earlier quoted context omitted.

> Terminal emulators display grids of characters using all sorts of horrifying protocols. What sort of "horrifying protocols"? The entire VT220 state machine diagram can be printed on a single letter- or A4-sized sheet of paper. That's the complete "protocol" of that particular terminal (and of any emulator of it). Implementing the VT220 with a few small extensions (e.g., 256 colors or 24-bit colors) wouldn't be too…

> VT220 state machine diagram can be printed on a single letter- or A4-sized sheet of paper. Does it cover Tek and ReGIS? Where can I find it?

https://vt100.net/emu/dec_ansi_parser

VT500 should include ReGIS

Re: The terminal of the future

#158

Post by fainpul »

rbanffy wrote: post #126
jcgl wrote: post #108

Earlier quoted context omitted.

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

I have a distaste for the verboseness of PowerShell, but I also have concerns with the attempt to bake in complex objects into the pipeline. When you do that, programs up and down the stream need to be aware of that - and that makes it brittle. One key aspect of the Unix way is that the stream is of bytes (often interpreted as characters) with little to no hint as to what's inside it. This way, tools like `grep` and…

> When you do that, programs up and down the stream need to be aware of that - and that makes it brittle.

You can go from object- to good old text processing with *nix tools no problem.

Instead of using 100% PowerShell to count all lines in the text files:

  gc *.txt | measure | select -ExpandProperty count
you can switch to `wc` if you like:

  gc *.txt | wc -l
`gc` is Get-Content – basically cat. You can also use awk, sed, jq etc.

Re: The terminal of the future

#159

Post by eikenberry »

LeicaLatte wrote: post #153

Instead of reinventing terminals, what if we standardized on structured data exchange between CLI tools (like JSON/msgpack) and let terminal emulators render it intelligently? The backwards compatibility problem that nixpulvis mentions is real - any "terminal of the future" needs to run existing tools well first while gradually enabling richer experiences.

Shell tooling is as successful today in large part due to it's simple byte string/file based protocol. Adding structured data types to the shell and shell command pipelining would turn it from something with a good UI but meh for scripting to one that is good at scripting but meh for UI. Shells are primarily a UI and the focus should stay on that.
Post reply on HN