- in Emacs' Eshell, one can pipe results in and out of buffers, e.g., you can run a command, then pipe it to grep/ripgrep, then pipe the results into a buffer (without any intermediate files).
- Conversely, you can read a buffer content and pipe it into a command.
- Or you can do simple calculations, you just need to use prefix notation e.g. `* 3 42` or `(* 2 pi)`.
- You can run regular emacs functions, like `dired .` or `magit-status`, `find-file ~/foo` or `(calendar)`.
- Or you can use Emacs vars and functions directly, e.g., `cd $org-directory`, or `cd (projectile-project-root)`, or `mkdir (format-time-string "backup-%Y%m%d")`
- You can absolutely delegate some (potentially long running) tasks to run in an outside terminal. I wrote this command eshell-send-detached-input-to-kitty¹, it uses Kitty Terminal's socket control feature.
There are integrations that you can only dream about, one recent example is John Wiegley (creator of Eshell) and Karthik (author of gptel package) having to experiment with piping things in and out of LLMs.
Sure, the backwards is also possible - you can emacs from a terminal, but terminaling from inside emacs is way more cooler.
___
¹ https://github.com/agzam/.doom.d/blob/main/modules/custom/sh...
In emacs, you can do this, because your email client is a package written in Lisp and running in the globally shared context of the emacs interpreter, so you can directly query its state. And if you don't know the names of the variables to query, you can trivially jump into the source code and start figuring it out. Furthermore, there is a 99.9% chance the state is implemented using well-known emacs primitives like buffers, whereas for general programs launched from the shell there is no standard set of UI and text manipulation libraries.
There isn't functionality in bash to magically jump to the C++ source code of Thunderbird or read variables from its internal state, which is the key difference.
A pro tip, if I may: never argue about programmability against a Lisp system. The argument unlikely to ever end up in your favor, because Lisp was designed from the ground up to be the ultimate programmable medium. The essence of Lisp lies in its incredible simplicity and flexibility - code is data, data is code, and everything can be manipulated programmatically.
The development experience is unmatched. You don't even need to save things - you can just eval them in a scratch buffer and see instant results. The REPL is unbelievably good, making programming feel like playing a video game where you get immediate feedback for every action. This interactivity transforms coding from a write-lint-link-compile-run cycle into a fluid, exploratory conversation with your system.
Sure, some things can be done equally well in shells, but not as nicely and elegantly as in a Lisp environment. The uniformity of S-expressions, the power of macros, and the ability to redefine anything at runtime give you a level of control that other systems struggle to match. Yours is a decades old argument yet Lisps are still prolific today, powering everything from Emacs configurations to modern web applications. The longevity speaks for itself - good ideas endure.
I love Clojure. I use it all the time. Sometimes through babashka, sometimes via nbb. Yeah, I would probably consider trading my dog if that gets me proper Clojure-like maps and other immutable structures in Elisp. Still, this would be far down in my wishlist for Emacs improvements. My biggest gripe is the improbability of removing the GIL - I would love to have proper concurrency, but that's not the Lisp machinery of Emacs, that's all C core.