Hacker News Reader

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

Right, the primitives are definitely different. But that's my point. The Unix primitives are simple and generic, which allows the user to quickly and easily adapt a disparate set of tools into an infinite number of workflows. The user is not required to also be a programmer[1]. If they are missing a specific tool, which is very rare, then it can be written in any language and integrated into existing workflows by following the simple design conventions. This generic interface is why programs written decades ago are still useful today. They don't need to be aware of how they're going to be used. They just need to follow the established design conventions.

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.

Emac's primitive are much more involved for sure. But the focus on having a simple and common representation for input and output instead of the separation between prompt and output has make it a lot easier to write involved tooling. Instead of a TUI application which breaks the unix philosophy or a script for a single workflow, you have both. The closest I think is now Vim+tmux, but it's now as easy to modify on the fly.

I use a personally-adjusted variant of M-x shell for most of my last 20 years of Emacs use (after trying various hacks including things mentioned in this article). I end up having about 20–100 named shell buffers on each machine, different projects, logs, etc, and I keep all histories of each shell in separate history files. It helps that the buffers are practically infinte size and I can use standard Emacs editing for anything, plus comint, which is a great simple interface to shells. I have some tools to split the Emacs frame into multiple pieces and reorganize them quickly so I can see any number of my open shells, limited only by the monitor size. I dont understand how people live without such shell management solutions; I’ve seen expert tmux users struggle with keeping track of all shells, whereas Emacs has tons of tools to work on buffers that directly work: starting from simple ibuffer, bookmarks, previews, to multi-occur (which can specialize to shells or subsets of them), to whatever you wish to do with buffers really.

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.

I think if you were to write a post (or better yet a video) to demonstrate your usage of your workflow, that would be a great resource! I love working in M-x shell but your workflow sounds next level.

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

Ah, that makes more sense. I'm not very familiar with the history.

I am well past the phase of trying to pull everything into emacs. All reasons to not use eshell you mention are valid, and I can add one more: vanilla eshell doesn't really work well with visual commands.

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.

Same here. I just use

https://github.com/akermu/emacs-libvterm

and

https://github.com/suonlight/multi-vterm

I never understood the need to do everything in Emacs either. I love Emacs, and I use it for all kinds of things, but the UNIX ecosystem has great tools too and it seems silly to have to choose one or the other.

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.

I agree. I do have a bunch of aliases that allow me to send the output of a command into an Emacs buffer, that open a file, open a file as root, open a file on a specific line and things like that which smoothen out the flow. However, I'm much more comfortable in the Emacs+Terminal environment than in pure Emacs.

> But Emacs' terminal experience pales in comparison to plain ol' xterm.

[lib]vterm reduces this paling to almost zero.

vterm is great - I had it in my config for a while and it's hands down the best way to put a terminal in Emacs. But for me it's the whole "encapsulate a terminal in Emacs" concept that I find unuseful. That's a personal preference though - I've been used to having dozens of xterms scattered around my desktops for longer than I've been using Emacs, so that's just more comfortable for me.

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.

There _used_ to be a huge advantage to pulling everything into emacs rather than having to background emacs, do whatever, then bring emacs back into the foreground. With multiple windows or multiplexers like tmux/screen, it's a lot less necessary, but still nice.

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

That's true, although I find that if it's a machine I'm going to be using for a while it's easier to go the WSL route and run Emacs from there.

vterm takes care of at least the vast majority of the display issues that emacsian shells typically suffer from. It's literally a shell as a buffer. htop and other curses based TUI's seem to run fine in it.

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.

eshell:

  Welcome to the Emacs shell
  ~ $ btop
  ERROR: Failed to get size of terminal!
  ~ [1] $

shell:

  $ btop                                                           
  Terminal size too small: Width = 79 Height = 22Needed for current config:Width = 80 Height = 24

If I increase the width and height, I get an extremely weird output.

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.

For interactive stuff you probably want eat https://github.com/kephale/emacs-eat or vterm

(I don't use them, I prefer my shells to last even if I should restart emacs)

Don't say that too loud or the "you should never have to restart Emacs" folks might hear you!

Visual programs won't work within emacs standard shell interaction. Only line oriented programs works (printing one line at a time and exiting). But for many visual programs, you have the equivalent in Emacs.

libvterm https://github.com/akermu/emacs-libvterm

M-x vterm

btop => https://i.imgur.com/wZowuzV.png

Does it have to be the GUI version of Emacs?

No. Vterm works fine even in a terminal version of emacs.