How I use my terminal

It is sad that we have to know how to configure tens of small utilities just to be productive. I ended up using emacs with some packages that I configure minimally, after spending a few hundreds of hours on ricing the shell, file managers, tmux, etc

Emacs is why I can't go back to terminals.

With Emacs one can do some shit in terminal that otherwise would just sound absurd. Like

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

Why is any of that absurd? That seems like typical terminal stuff.

Not really. The point is you're interacting with the full-blown Lisp development environment that is emacs and all the software it contains. A normal terminal doesn't let you reach into the internals of the software you're running in it, it just lets you chain that software together in predetermined ways.

All the thugs you listed could be done within the shell. Shells are very programmable.

Imagine I launch an email client like Thunderbird from the shell. In a separate window I want to write a script that takes the currently displayed mail message in that client and runs "grep" on it. I can't do that, unless the authors of the email client have gone out of their way to expose an API that allows you to manipulate its state programmatically.

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.