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

61–70 of 174 posts

Re: The terminal of the future

#61

Post by skydhash »

robot-wrangler wrote: post #50
skydhash wrote: post #13

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…

> Acme: Got a link to what you meant? This is pretty hard to search for. > - Emacs One thing in common with emacs, jupyter, vscode.. these are all capable platforms but not solutions, and if you want to replace your terminal emulator by building on top of them it's doable but doesn't feel very portable. I'd challenge people that are making cool stuff to show it, and then ship it. Not a pile of config + a constellatio…

> 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 all the editor commands are available like cli tools.

- comint: All things REPL (sql client, python,...)

- shell-command and shell-mode: The first is for ad-hoc commands, the second is derived from comint and give you the shell in an REPL environment (no TUI).

- term: terminal emulator, when you really want a tui. But the support for escape sequences is limited, so you may want something like `eat` or `vterm`.

- compile: all things build tools. If you have something that report errors and where those errors are located in files, then you can tie it to compile and have fast navigation to those locations.

- flymake: Watch mode for the above. It lets you analyze the current file

- ispell and flyspell: Spell checking

- dired: file management

- grep: Use the output of $grep_like_tool for navigatoin

- gnus and rmail: Everything mail and newsgroup.

- proced: Like top

- docview: View pdf and ps files, although you can probably hack it to display more types.

- tramp: Edit files from anywhere...

And many more from utilities (calc, calendar) and games to low level functions (IPC, network,...) and full blown applications (debugger, MPD client). And a lot of stuff to write text and code thhings. All lisp code, with nice documentation. That's just for the built-in stuff.

If not for the state of the Web, you could probably just went straight from init to Emacs.

Re: The terminal of the future

#63

Post by zzo38computer »

robot-wrangler wrote: post #60
zzo38computer wrote: post #52

Earlier quoted context omitted.

There are many downsides. There are problems with using JSON for this; other formats would be better. JSON needs escaping, cannot effectively transfer binary data (other than encoding as hex or base64), cannot use character sets other than Unicode, etc. People think JSON is good, but it isn't. Also, you might want to use less or other programs for the text output, which might be the primary output that you might also…

I guess I don't see those as big downsides because I don't think people usually want binary data or quoted strings back from a CLI command, nor do they want column oriented output, nor "user friendly" tables. Answering --help with JSON is a good example, how bad is it really if the response is JSON? Well, using less works fine still and you can still grep if you want simple substring search. Wanting a section is prob…

Structured output would be helpful in many ways, but JSON is not a good format for this (neither is YAML nor XML nor HTML).

> JSON's not perfect but (non-minified) it's human-readable enough to address the basic issues here without jumping all the way towards binary or (shudder) HTML

It does not address most of the real issues. Programs that deal with pictures, sounds, non-Unicode text, structures of the kinds that JSON does not have, etc, will not do as well; and the input/output will involve converting escaping. (One format that I think is better is DER, although, it is binary format. I did write a program to convert JSON to DER, though.)

Re: The terminal of the future

#65

Post by robot-wrangler »

zzo38computer wrote: post #63
robot-wrangler wrote: post #60

Earlier quoted context omitted.

I guess I don't see those as big downsides because I don't think people usually want binary data or quoted strings back from a CLI command, nor do they want column oriented output, nor "user friendly" tables. Answering --help with JSON is a good example, how bad is it really if the response is JSON? Well, using less works fine still and you can still grep if you want simple substring search. Wanting a section is prob…

Structured output would be helpful in many ways, but JSON is not a good format for this (neither is YAML nor XML nor HTML). > JSON's not perfect but (non-minified) it's human-readable enough to address the basic issues here without jumping all the way towards binary or (shudder) HTML It does not address most of the real issues. Programs that deal with pictures, sounds, non-Unicode text, structures of the kinds that J…

For raw data type of applications, it's definitely important to be able to preserve pipeline oriented use-cases like `cat img.png | convert-stdin-to-jpg | convert-stdin-back-to-png | imgcat`. But in the hypothetical world where all CLI I/O moves towards JSON, I'd still argue this is not only possible but now strictly easier because you can just explicitly embed mimetype info + b64 instead of assuming/detecting encoding or requiring user to specify it, or working with heuristic file-magic. (Jupyter notebooks work like this to persist images instead of just flat text.) And presumably a smarter suite of JSON oriented tools like jcat/jless would either actually display that data, or notice the type and avoid spamming the screen with raw b64.

Re: The terminal of the future

#66

Post by robot-wrangler »

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

Earlier quoted context omitted.

> Acme: Got a link to what you meant? This is pretty hard to search for. > - Emacs One thing in common with emacs, jupyter, vscode.. these are all capable platforms but not solutions, and if you want to replace your terminal emulator by building on top of them it's doable but doesn't feel very portable. I'd challenge people that are making cool stuff to show it, and then ship it. Not a pile of config + a constellatio…

> 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 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. That would mean that you open it up to a shell prompt with a dollar sign, you can hit ctrl-t to get a new terminal tab. Clicking URLs should open them in a browser without having to copy/paste. Speaking of copy/paste, that should work too, and ctrl-e, and ctrl-a, etc, etc.

Re: The terminal of the future

#67

Post by wredcoll »

anon7725 wrote: post #58
mrandish wrote: post #26

Earlier quoted context omitted.

Yes, this was my first thought too. I haven't used a hardware text terminal since the 80s so maybe I don't get where the TFA is coming from? It starts out by stating "This post is part 6 of a multi-part series called 'the computer of the next 200 years'". Given that context, why is the focus on the evolution of 1980s VT100-type protocols? I'm at home and there are over a half dozen different devices within 25 ft whic…

I don’t know how you work, but I spend a good portion of my day in a terminal while working on AI-type projects. The terminal never left.

I'd like to make the distinction between text, indeed, word/command based interfaces and "terminal".

It so happens that right now one is synonymous with the other but there's no instrinsic requirement.

There's probably something to be said for the inherent constraints imposed by the terminal protocol, but, again, we can build the same things without that.

Re: The terminal of the future

#68

Post by wredcoll »

unixplumber wrote: post #21
wredcoll wrote: post #4

Earlier quoted context omitted.

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.

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

I haven't personally implemented one but I'll quote someone who has spent a lot more time on it:

> Many of these implementations are ad-hoc, one-off solutions. They aren't using any shared library or codebase.2 Terminal emulation is a classic problem that appears simple on the surface but is riddled with unexpected complexities and edge cases.3 As a result, most of these implementations are incomplete, buggy, and slow.4 [1]

(I mean, it's possible html/css deserves to be called horrible also but they produce an undeniably superior result)

[1] https://mitchellh.com/writing/libghostty-is-coming

Re: The terminal of the future

#69

Post by 7e »

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.

Re: The terminal of the future

#70

Post by skydhash »

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…

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 terminal like xterm and Terminal.app, but I have eat installed and it's working great.

Post reply on HN