Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Take Two: Eshell

yummymelon.com

Post reply on HN
Print view View original

31–40 of 69 posts

Re: Take Two: Eshell

#31

Post by eschneider »

spauldo wrote: post #10
imiric wrote: post #4

I've been using Emacs daily for well over a decade now, but I just can't get myself to use any of its shells, or features that replace standard shell workflows. 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 descri…

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…

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.

Re: Take Two: Eshell

#33

Post by senkora »

mystifyingpoi wrote: post #23
log101 wrote: post #2

I wish someone could write a "The Good Parts" book for Emacs. Even after reading the manual twice, I'm still overwhelmed with the API and forget even the most basic configuration options after a month of inactivity.

I have the same feeling with Vim after using it for like the past 10 years professionally. Granted, it is much smaller, but for instance editing multiple files using just stock config is surprisingly undiscoverable. It comes with the whole buffer mechanism, which is certainly powerful, 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 :l…

I did find the Vim manual to be a high-value read for basic editing, for what it’s worth.

It’s pretty short and I felt like most of it was useful.

Re: Take Two: Eshell

#34

Post by ethan_smith »

log101 wrote: post #2

I wish someone could write a "The Good Parts" book for Emacs. Even after reading the manual twice, I'm still overwhelmed with the API and forget even the most basic configuration options after a month of inactivity.

Doom Emacs (https://github.com/doomemacs/doomemacs) essentially serves this purpose with its curated, modular configuration and excellent documentation that focuses on the most useful parts while hiding complexity.

Re: Take Two: Eshell

#35

Post by ndegruchy »

I feel like most folks misunderstand Eshell when going into it. It's not really their fault, as they _expect_ something bash-like, and in many ways it is. However, Eshell is _not_ bash. It's not zsh. It's not fish. It's Eshell. When you use Eshell, you get a marriage of command-line tools and Emacs. This isn't always the best case, and some tools are awful to try and use in Eshell.

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.

Re: Take Two: Eshell

#36

Post by fn-mote »

unixhero wrote: post #32

The writer is incredibly knowledgable. But all of this is completely unapealing. To me this isn't power, it is just learning a lot more things.

The power comes from the ease with which you can adapt your workflow to varying requirements.

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.

Re: Take Two: Eshell

#37

Post by kstrauser »

ethan_smith wrote: post #34
log101 wrote: post #2

I wish someone could write a "The Good Parts" book for Emacs. Even after reading the manual twice, I'm still overwhelmed with the API and forget even the most basic configuration options after a month of inactivity.

Doom Emacs ( https://github.com/doomemacs/doomemacs ) essentially serves this purpose with its curated, modular configuration and excellent documentation that focuses on the most useful parts while hiding complexity.

Doom is really cool and I appreciate the devs’ hard work. It’s seriously impressive.

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.

Re: Take Two: Eshell

#38

Post by imiric »

skydhash wrote: post #21
imiric wrote: post #4

I've been using Emacs daily for well over a decade now, but I just can't get myself to use any of its shells, or features that replace standard shell workflows. 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 descri…

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

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.

Re: Take Two: Eshell

#39

Post by cmrdporcupine »

ndegruchy wrote: post #35

I feel like most folks misunderstand Eshell when going into it. It's not really their fault, as they _expect_ something bash-like, and in many ways it is. However, Eshell is _not_ bash. It's not zsh. It's not fish. It's Eshell. When you use Eshell, you get a marriage of command-line tools and Emacs. This isn't always the best case, and some tools are awful to try and use in Eshell. Eshell shines when you're looking t…

Yes it may be the case that the achilles heel of Eshell is that it tries to be too bash-like. Just making it clear that this is an "elisp thing that interacts with both emacs and your system" and call it "dialog" or "interactive scripter" or something and dispense with following normal shell conventions (while still offering tab completion etc) might have been wiser.

Re: Take Two: Eshell

#40

Post by imiric »

em500 wrote: post #17
imiric wrote: post #4

I've been using Emacs daily for well over a decade now, but I just can't get myself to use any of its shells, or features that replace standard shell workflows. 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 descri…

> 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.
Post reply on HN