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.
- 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.
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.
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.
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.
> 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.
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.)
> 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”.
A solution build upon Emacs is trivially portable by utilizing a custom init.el, setting the user-emacs-directory variable, and a script/desktop entry running Emacs with it. A solution build upon anything is, in theory, portable utilizing Nix/Guix.
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.