Take Two: Eshell
I think the main reason—besides muscle memory and the scripts, aliases, and commands I'm already used to—is because a POSIX-compliant shell exposes a generic interface for both programs and users. Programs can receive and output data over standard file descriptors. They have a CLI with common design conventions regarding flag and argument parsing. Some programs choose not to follow these conventions, and some have a very complex CLI, but for the most part users can expect a specific interface to exist. Man pages have a standard format, and way of accessing them for all programs. And so on. All compliant shells on Unix-like systems work in a similar way, which means that the workflows I'm already used to are easily transferrable to any other system.
Contrast this with the workflow table in TFA. It's a mishmash of different Emacs modes, each with their own quirks, UI, and ways of interacting with other modes. One could say that Elisp ties it all together, but it's a general purpose programming language which obviously doesn't enforce a cohesive user interface for packages to follow. Eshell even complicates this because it resembles a POSIX shell, but doesn't follow any Emacs interface guidelines, so it breaks conventions of both sides. Sure, I could force myself to learn the intricacies of each package over a long time, and create a cohesive Emacs configuration that works for me, but I would need to lug around that configuration and depend on Emacs for everything. Which I'm sure Emacs purists would claim is the way to go, but I don't like that. The beauty of Unix systems is the ability to easily replace any tool in your workflow without impacting everything else. For example, I've mostly replaced `ls` with `eza`, `grep` with `rg`, `find` with `fd`, `top` with `btop`, etc. These were essentially drop-in replacements with minimal impact to me. Consider what it would take to replace dired or Magit, as perfect as they might be.
The Unix "small programs that do one thing well" philosophy is often ignored, unfortunately. Emacs might be the single biggest offender of it, though I suppose it's to be expected since "GNU's Not Unix"... The benefit of it is precisely the flexibility it gives to users. As much as I love Emacs, I'm not married to it, so relying on one special program that does many things would be harmful for me in the long run if a better alternative appears in the future.
Calling shell commands from Emacs and inserting their output into a buffer is great, don't get me wrong. But Emacs' terminal experience pales in comparison to plain ol' xterm.
At the end of the day, I use the tool I'm most comfortable with and does a good job. Sometimes that's Emacs, sometimes it's not. Maybe if I hadn't spent 20 years in the shell before picking up Emacs I'd feel differently.
but the UNIX ecosystem has great tools too
well, the big advantages start when you aren't in the UNIX ecosystem. One of the biggest benefits of using Emacs and Eshell heavily for me is, I have it on a Windows machine.
But Emacs' terminal experience pales in comparison to plain ol' xterm.
[lib]vterm reduces this paling to almost zero.
I'll use regular ol' shell occasionally when I just need to throw around some commands but for anything that needs a real terminal emulator I just open another xterm.
These were essentially drop-in replacements with minimal impact to me. Consider what it would take to replace dired or Magit, as perfect as they might be.
There's a difference of philosophy there. The Unix way is a good concept to align software, but it's not the only one. In Emacs, the primitives are different. Instead of having pipes, redirectors, thinking in terms of lines,... What you have are buffers, windows to displays those buffers in, frames to hold those windows, a lot of functions to manipulate the text in buffers and keybindings to activate those functions. There's also the minibuffer for input and the echo area for messages.
So using those people creates packages that solve each a particular task. But the packages are not closed programs you compose together. They are both libraries and a particular way to use the library. If it does not fit your purpose, you alter it. If it's missing something, you add it. If your workflow requires two or more packages, you link them together, creating a metapackage for that workflow.
So Emacs is something to mold to your own needs. The default configuration is just the most common and the traditional way to do stuff. It's not lego bricks like the Unix way, it's clay. You don't replace ls with eza, you turn ls into eza.
In contrast, if a specific Emacs package doesn't do what the user needs, they must use Elisp to change it, or write their own package. Integrating packages in a cohesive workflow also requires programming, and each integration is special because every package has its own quirks and API. This might be second nature to some Emacs gurus, but I don't want to program whenever I need to change my workflow. I'm sure that I could eventually build the perfect operating system for me this way, but I'd rather rely on an extensive ecosystem of tools written by others.
[1] I would argue that shell scripting is not programming, for better or worse. It's often the best tool for the job for getting things done quickly, but for more sophisticated tasks a programming language is a better fit.
btop/htop/nvtop or other curses-heavy tools have specialized solutions (open vterm or eat and run it), but all the composing unix tools run in M-x shell.
The Unix "small programs that do one thing well" philosophy is often ignored, unfortunately. Emacs might be the single biggest offender of it, though I suppose it's to be expected since "GNU's Not Unix"...
It's not because of GNU (which is a Unix workalike), but because Emacs originated on ITS and Genera Lisp Machines, which were truely very non-UNIXy environments.
But recently I installed eshell-eat, and my biggest paint point just went away.
I never expected to use eshell as a full-blown terminal replacement. I use half A dozen aliases (find-file dired...) , some lightweight lisp scripting, git that, apt install there... That's about it.
In that capacity it's a valid quick tool.
I mean do what works for you of course, but I found it a vast improvement over the historical emacs shell things, which I've also used for decades.
Welcome to the Emacs shell
~ $ btop
ERROR: Failed to get size of terminal!
~[1] $
$ btop
Terminal size too small: Width = 79 Height = 22Needed for current config:Width = 80 Height = 24
ansi-term:
Same as shell.
Any other Emacs shells I missed?
In any case, I do not use any shells within Emacs. I use XTerm separately.
(I don't use them, I prefer my shells to last even if I should restart emacs)
https://github.com/akermu/emacs-libvterm
and
Blessing and a curse ? Maybe they should rebrand emacs as a universe and not an editor.. so that people know there are many galaxies to explore
What is more challenging is actually customizing Emacs to suit your own preferences, which is the main reason you would want to use it. Deciding which external packages to install, how to use and customize them, and writing your own packages. That is a lifelong endeavor and learning experience, just like programming. So it's to be expected that someone might be a long-time Emacs user, but not be aware of some of its features. You're not expected to know everything, nor do you need to. Just learn as much as you need to make it useful for you. Essentially, every Emacs installation is different, since it's purpose built for a specific use case according to very specific preferences. There's no singular "Emacs". And that is a beautiful thing. :)
Saying this as somebody who's been coevolving with emacs for 20 years already. Oh, all the little bits of lisp, all the mechanical memory, all the IDEs that came and went...
My emacs survived them all!
At this point, I believe that newcomers should jump straight to Neovim and file manager plugins, than deal with the stock stuff. That's just one thing out of many.
but I guess that 99% of newcomers just want to open tabs and go left/right, not to learn set of byzantine commands like :rewind or :last.
There's nano and multiple other editors for that. You want vim for a more powerful interactions than go left and write.
My need for vim is to open a file, go the the place I want to, quickly edit it, and go back to what I was doing (which is reading and thinking). Editing is just a short bust instead of being a continual activity.
Another annoyance with editors like VS Code (and the like) is how tedious to have information. Every file is in own tab (even though you can show more at once, but that's tedious). So you are always flipping back and forth. With vim, I can have everything at once in front of me, and once I have a clear line of action collapse it to the few (2 or 3) I need. Also quickly.
Vim and Emacs are for those that really needs them. There's a lot to learn, but that's because there's a lot you want to do.
It's quite possible you just don't need Emacs.
Look at the tutorial - it does everything it can to encourage you not to use the arrow keys or PGUP/PGDN. No, you're supposed to learn all kinds of whacky key combinations instead. That's all for a good reason but it's hardly encouraging for new users faced with the choice of doing things the "proper" way and building new muscle memory vs. using the keys they already know.
If all you want is a decent editor to get some work done without having to spend a fair amount of time learning the editor itself, Emacs probably isn't the best choice.
(To others reading this comment: Emacs editing commands have a hierarchy of sorts. It's powerful, and context-aware. But it requires you to internalize things like CTRL-f to move the cursor to the right. Unless you make the effort to learn them - or use evil-mode - you miss out on a good chunk of what makes Emacs so great for editing.)
But. Doom is an uncanny valley for me. It looks like Emacs, but feels like something else entirely, something unlike I’ve ever used before. If you want to use all the things available inside Emacs without learning the “bare” version, right on. But if you actually want to learn Emacs, in my opinion, Doom isn’t it. It’s its own thing, and it’s a fine thing, but whatever it is, to me, it ain’t Emacs.
There are many great applications and compatibility layers written to run on Emacs:
- Evil for a decent editor,
- calc for a good, flexible calculator,
- magit for version control,
- smerge for conflict resolution,
- dired, org, notmuch, tramp, eshell, outshine, comint, htmlize, etc.
and each of them deserves a "the good parts" book!
For understanding Elisp, I wrote an "Elisp Cheetsheet for Python Programmers" to help as a reference.
forget even the most basic configuration options after a month of inactivity
So do I. ChatGPT4o and the like of course do not forget, and they've read more documentation, library code, and message forum postings than any human could. They know all the five or so ways to initialize per-buffer variables and will write you little snippets of Elisp to add to your .emacs or .dir-locals.el or per-file headers/trailers.
So, if Org-mode or multi-occur aren't doing what I want, and `M-x info-emacs-manual` doesn't make it obvious, ChatGPT4o is my next recourse.
Eshell shines when you're looking to use Emacs to do stuff in the shell, but not really deal with the shell itself. It will dutifully run whatever program you feed it, but the real magic is when you want to deal with the output. You can redirect outputs to buffers, which you can then manipulate with Emacs familiarity. You can even handle remote sessions just as easily as you would open a remote file in TRAMP. I've used this on many occasions to edit a remote config file, then trigger Eshell, which puts me in that directory, to then restart the service without having to launch a separate SSH session or terminal.
While there are a lot of clunky bits of Emacs, I feel like Eshell gets an especially bad rap. Some of it's justified: It presents itself as a bash-like interface, while actually having vastly different ways of handling things. I feel like folks don't really get the idea that it's an interactive Emacs session, a worksheet for the command-line that lets you ingest data from external tools in a more ergonomic way than doing `shell-command` or similar.
But what I really want is eshell outside of emacs. In fact I want all the bits of emacs outside of emacs.
The problem with eshell is the problem with emacs. It's a monolith. I know I know that's also its strength, but what I really want is for all the bits of emacs to be exploded out into components that make up an overall environment (yes, yes, Genera/Lisp Machines).
Unlike emacs purists, I am too much in and out of that environment to really ever feel fully comfortable adopting all its tools as my mainstay tools.
But what I really want is eshell outside of emacs
https://www.gnu.org/software/emacs/manual/html_node/eshell/S...
However, despite disliking python, I found https://xon.sh/ to be really excellent and provides a lot of the benefits of eshell, but better, in my humble opinion: it has a well-enough structured base language that is essentially already built to be a library glue-code language, which works really well with the unix philosophy that traditional shells utilize (a good library is just a tool that does a thing really well). It's really nice to just do things like this example
from somelib import process_image #returns a file name that it saved to
for f in $(some_executable_that_prints_a_file_list).strip().split("\n"):
img = cv2.imread(f)
cp @(process_image(img)) publish_dir
make publish
If this description doesn’t cover areas you need to work in, forget it.
An example: you need to do a bunch of work in a pipeline, but at one point during development you want to stop, examine the output, possibly edit it, and then finish the pipeline. In this case, doing the work in emacs feels good because you can put the intermediate results in a buffer. Not life changing, but nice.
For file management these days, Dired is my interface of choice. It is simply the more elegant tool for the job. Case in point: renaming a bunch of files in a directory to arbitrary names. With a shell, my standard approach would have been to run some variant of `ls -1 > foo.sh`, edit `foo.sh` to insert `mv` on each line to a renamed target file, `chmod u+x foo.sh` to be executable, run `foo.sh`, delete `foo.sh` and call it a day.
I used to do this before I discovered vidir.[1] vidir is not actually tied to vi; it lets you rename and delete files through your `$EDITOR`. You edit a temporary file that looks like this:
...
0093<tab>./fstab
0094<tab>./fuse.conf
0095<tab>./fwupd
...
I'll give Emacs another try some day, I swear, and Dired is one of the reasons.
Edit:[1] I linked to https://github.com/trapd00r/vidir here at first. That is a fork; vidir comes from https://joeyh.name/code/moreutils/. You probably want the original. It is packaged for Debian, FreeBSD, Homebrew, etc. as part of the package `moreutils`.
Besides meaning vi + dir, the Icelandic name means "willow tree", which is a cool name for a directory traversal tool.
Shout out to moreutils, there are many nice utilities, and there's a `moreutils` package in most distributions.
Update: Looking at the authors listed in the man pages, the `trapd00r` version looks to be a fork of the moreutils version. Not sure how the functionality compares. Both versions seem to have been updated since the fork.