Emacs: Mastering Eshell | Hacker News Reader

Emacs: Mastering Eshell

masteringemacs.org

157 pointssigna1140 comments

Cool, as a user of Emacs for 35+ years, I had never looked at eshell. I bookmarked the link. I recently discovered both treemacs for rapid file navigation as well as a better way to setup Emacs, so Emacs has once again become a large part of my workflow. I use the LispWorks IDE a lot, and the editor is Emacs-like, but Emacs is great because it supports every programming language I use.

BTW, the author’s book Mastering Emacs is very good; I bought a license last month.

I'm a long-time vim user, but I like to program the parens-y languages, so tried my hand at emacs a while back.

Somehow, over decades, I had never heard about this cross-platform shell built into emacs. There doesn't seem to be much fanfare about it (at least from an outsider's perspective), but having a consistent shell available on any platform emacs runs on is really cool.

I'm also a a long time vi user. I can't say why you hadn't heard about Eshell. I can say that Emacs has several such shell/terminal things most with different approaches.

My own most recent experience was I did a weekend experiment to switch over to Emacs. I've been trying to find more and more reasons to write various flavors of Lisp. My experiment was going well until I got to this part of Emacs. I realized a lot of my existing workflows depend on at some point bringing text into the editor, composing more text and sending it to the shell. From a programming perspective the different approaches I tried in Emacs (Eshell, dired and at least two more) seemed really cool, but the performance was unacceptable. I was left with blank screens, flashing cursors and scraps of text.

Does someone know is there one of the Emacs approaches to interacting with a shell or performing shell-like activities, that has dramatically better/native-like performance?

One major problem is Emacs's poor performance when lines get really long (e.g. 1 MB). That's rarely a problem when using Emacs as a text editor, but it can happen quite a lot when running shells.

I've managed to avoid this by setting my shell to a script which pipes bash through GNU fold, so long lines are broken up before Emacs ever sees them (around 1000 characters; slightly earlier if there's whitespace). Rather extreme, but I really like shell-mode (not really a fan of eshell)

There was a recent (a couple of weeks ago) commit that claims to rectify the long lines performance issue, for what it's worth.

That is really interesting. May you take the effort and identify the commit?

EDIT: Nevermind, search to the rescue

This might be the discussion: https://lists.gnu.org/archive/html/emacs-devel/2022-08/msg00...

These might be the commits: https://git.savannah.gnu.org/cgit/emacs.git/commit/etc/NEWS?...

https://git.savannah.gnu.org/cgit/emacs.git/commit/etc/NEWS?...

Also this one I think: https://git.savannah.gnu.org/cgit/emacs.git/commit/?id=616da...

Just tried it out. For my personal workflow when working on overlong lines, the performance gain is HUGE! From unusable to actually decent. Not using find-file-literally and even syntax highlighting enabled.

That's great to hear, thanks! I haven't tested it in anger yet, and I'm not going to pretend to understand the display-code changes.

FYI newer versions of emacs are supposed to handle long lines better

Thanks, I’ve faced this issue but didn’t know about gnu fold.

Be aware that bash doesn't like being piped, and changes some of its behaviour. I work around that using expect:

- Here's the script itself https://github.com/Warbo/warbo-utilities/blob/master/raw/wra...

- Here's the accompanying expect file https://github.com/Warbo/warbo-utilities/blob/master/raw/wra...

- Here's my patched version of GNU fold, which removes some buffering https://github.com/Warbo/warbo-utilities/blob/master/raw/fol...

- Here's the resulting Nix package (along with some tests) https://github.com/Warbo/warbo-utilities/blob/master/scripts...

emacs-libvterm is bundled in Doom I think. This is how (I think) I ended up hearing about it from a friend (I don't actually use Doom). It's great. It has a very intuitive resolution to the issue of processing emacs keystrokes vs. terminal input, and it has a "copy-mode" that lets you grab output from the terminal.

vterm

Tangential, but I've been playing around with Clojure lately. I thought my days of actually-using-vim were behind me as I just use the vim plugin in VS Code for my day job but I found that the most mature Clojure VS Code plugin (Calva) doesn't work great with vim keybindings so I decided to see how neovim had progressed (hadn't looked at it in a few years).

I ended up getting setup really easily with Conjure[1]. It's a neovim plugin written in Fennel[2], a Lisp dialect that compiles to Lua. I'm writing my whole neovim configuration in lisp. It sounds like the setup to some emacs vs vim joke but it's actually pretty cool!

[1] https://github.com/Olical/conjure

[2] https://fennel-lang.org/

Yes, I moved the other way and have been using vim for last two years or so. Eshell is the only main thing I still miss from emacs despite not being a lisper.

I have found it quite hard to explain others what exactly is great about eshell, because most people instinctively equate it with embedded terminals found in vscode etc. But it is really nice to have a shell where you can do most of the things you could in bash/zsh and also have complete programmatic access to the editor environment.

Check out Doom Emacs, I was a long term vimmer then picked up Doom and it converted me pretty quickly over to an Emacs guy now.

Same for me. I've been using emacs now for several years after being a long time vim user. I have never missed vim after switching. Emacs is amazingly powerful. And I never got to a point where Doom felt limiting. I only ever need to make minor customization on top of Doom's packages and it's super easy and I actually like elisp _way_ better than vimscript.

Anyways I don't really care for text editor wars or whatever. I just wanted to second this person's experience with vim -> emacs via Doom Emacs.

I'm in the same boat, made the switch for the org-mode ~month ago. Doom is amazing, and most of my custom config was not necessary, the default modules are super sane.

I do miss nvim's configuration in lua though.

Doom Emacs convert of about 4 years here, and Evil mode user for about 6 and I summarize my thoughts with: vim is the best text editor, it just happens that the best implementation is inside Emacs.

> There doesn't seem to be much fanfare about it

I think there's two sides. The people who aren't familiar with Emacs will ask why should I care about this, and the people who are familiar with Emacs will most likely already know of the power that Emacs can bring and when faced with eshell for the first time just think "of course Emacs can do that, it's Emacs after all"

Have you seen the new VIM shell in 8.1?

Found it hard. Instead just gvim or macvim with vim lisp adoption.

More Eshell goodies:

Inline images: https://xenodium.com/wizard-zines-comics-eshell-util

Snippet expansion: https://xenodium.com/yasnippet-in-emacs-eshell

Imenu: https://xenodium.com/imenu-on-emacs-eshell

Company completions: https://xenodium.com/eshell-pcomplete-company-completion

Nice, but I have moved to https://github.com/akermu/emacs-libvterm and I'm not looking back

I love vterm. It's so good.

eshell is platform-agnostic, whereas vterm is not for Windows.

One mildly annoying thing about eshell is the lack of input redirection. I can most of the time rewrite my command to not use an input redirection or use some other emacs feature to do what I want (eg M-x sql-postgres), but out of habit, I trip over myself sometimes in eshell with respect to this.

Weird, I submitted the exact same link yesterday and the dupe detector didn’t trigger: https://news.ycombinator.com/item?id=32477938

No worries, it’s a great article and I’m glad folks are reading it!

HN's dupe detector only kicks in if a story has already had significant attention (see https://news.ycombinator.com/newsfaq.html). We leave it porous to partly mitigate the randomness of what gets noticed on /newest — we want good stories to get multiple cracks at the bat!

In the future we'll have some sort of karma sharing so earlier submitters get credit also.

I think there’s a “noise gate” on the dupe detector…by which I mean it is more likely to trigger the more traction a story previously received.

Except there also seems to be an “LRU cache” to the dupe detector as well, so after some period of time stories aren’t considered duplicates at all. That is to say, that they are treated as evergreen.

Of course this is entirely speculative, but it is no longer like the hard dupe detection of the old days.

The type command seems to be missing.

I just tried it:

    $ type type
    type is a shell builtin

What version? On 29.0.50 I get

    $ type type
    type: command not found

Same. Try running `emacs -Q` to rule out your own customizations.

emacs is not UNIX

well it’s GNU

it’s a parallel universe

it’s an OS

UNIX makes more sense, actually

I love emacs (and lisp) but I don’t like it

If you use ITS for a while, you'll understand why Emacs is like it is. Also some of the other GNU projects.

what does ITS mean ?

Incompatible Timesharing System: https://en.wikipedia.org/wiki/Incompatible_Timesharing_Syste...

You love it but don’t like it… hmmm

Reply on news.ycombinator.com