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.
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.
and all it took was a deep understanding of software development, experience with lisp and a bunch of your own time coding and debugging! what a piece of software!
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 people, why not add it to something other than 1970s terminal text editor? surely an LLM plus lisp can do more of these inane tricks than a 70s text editor plus lisp?
programmatic text manipulation
You're saying this with derision, but the ability to quickly add "incredibly specific-to-you" features is precisely what is so cool about it!
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.
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 constellation of plugins at undeclared versions + a "simple" 12-step process that would-be adopters must copy/paste. That's platform customization, not something that feels like an application. Actually try bundling your cool hack as a docker container or a self-extracting executable of some kind so that it's low-effort reproducible.
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.
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.
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.
1. Install Emacs
2. git clone --depth 1 https://github.com/doomemacs/doomemacs ~/.config/emacs
3. ~/.config/emacs/bin/doom install
Now open Emacs and stuff just works. You can customize it later if you want.
I agree with your general point. People mostly want stuff that just works. Very few want to become experts (and nobody can be an expert in everything.)
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.
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”.
It's part of plan9:
- 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.