Take Two: Eshell
yummymelon.com
Take Two: Eshell
1–10 of 69 posts
Re: Take Two: Eshell
#2I 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.
Re: Take Two: Eshell
#3I 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.
No matter you do, inactivity means forgetting. Why do you need the api memorised if you don't use them?
I mean, using the editor itself means maybe 10-15 keys/commands.
Mastering Emacs is a good overview, btw.
Re: Take Two: Eshell
#4I'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 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.
Re: Take Two: Eshell
#5I'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 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.
Re: Take Two: Eshell
#6I'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…
Same here. I just use
https://github.com/akermu/emacs-libvterm
and
Re: Take Two: Eshell
#7I'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…
eshell:
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.
Re: Take Two: Eshell
#8I 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.
There's truth to this. Emacs is large. I tried RTFM twice, thrice .. not skimming, taking time. And even then I learn later that there was some feature in it that I completely missed. And it's a common joke in the community "I've been using emacs for decades and I didn't know that...".
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
Re: Take Two: Eshell
#9I 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.
There's truth to this. Emacs is large. I tried RTFM twice, thrice .. not skimming, taking time. And even then I learn later that there was some feature in it that I completely missed. And it's a common joke in the community "I've been using emacs for decades and I didn't know that...". Blessing and a curse ? Maybe they should rebrand emacs as a universe and not an editor.. so that people know there are many galaxies…
The thing is that you don't really learn Emacs. Emacs is just an interface to programs written in Elisp that happens to have editor-like functionality out of the box. There are specific conventions it follows, and Elisp has its own set of quirks and a steep learning curve if the user is not fluent in other Lisp languages, so those can be challenging to learn. But boiled down to its core, there's not much to Emacs itself. It's actually a pretty bad editor OOB, but that might be subjective.
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. :)
Re: Take Two: Eshell
#10I'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 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.