←back to thread

298 points miguelraz | 1 comments | | HN request time: 0s | source
Show context
skydhash ◴[] No.45893684[source]
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 arranged in a tiling manner in a frame. And you can have several frames. As the buffer in a window as the same grid like basis as the terminal emulator, we can use cli as is, including like a terminal emulator (vterm, eat, ansi-term,...). You can eschew the terminal flow and use the REPL flow instead (shell-mode, eshell,...). There's support for graphics, but not a full 2d context.

- Acme: Kinda similar to emacs, but the whole thing is mostly about interactive text. Meaning any text can be a command. We also have the tiling/and stacking windows things that displays those texts.

I would add Smalltalk to that, but it's more of an IDE than a full computing environment. But to extend it to the latter would still be a lower effort than what is described in the article.

replies(4): >>45893829 #>>45894322 #>>45895572 #>>45896873 #
spudlyo ◴[] No.45894322[source]
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 the resulting PDF to my LLM context. Then my code calls gptel-request with a custom prompt and I get an async elisp callback with the OCR'd PDF now in Emacs' org-mode format, complete with italics, bold, nicely formatted tables, and with all the right macrons over the vowels, which I toss into a scratch buffer. Now that the chapter from my textbook in a markup format, I can select a word, immediately pop up a Latin-to-English dictionary entry or select a whole sentence to hand to an LLM to analyze with a full grammatical breakdown while I'm doing my homework exercises. This 1970s vintage text editor is also a futuristic language learning platform, it blows my mind.

replies(2): >>45897165 #>>45899964 #
slickytail ◴[] No.45897165[source]
As a non Emacs user, I would be really interested in a full writeup of how this works.
replies(2): >>45898392 #>>45900519 #
medstrom ◴[] No.45898392{3}[source]
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.

replies(1): >>45898976 #
1. kragen ◴[] No.45898976{4}[source]
Yes, but what keystrokes and which packages are you using? Elpa versions or a fork from elsewhere?