I've found it quite good, but more compelling is that when you want to add new completions you can use lisp instead of some crazy one off half language.
Eshell works, but it does not use term.el, and so has terminal compatibility problems with many utilities (the progress indication of curl or homebrew, for example). I have found it much more practical to stick with zsh, but use ansi-term or multi-term to launch the shell from inside Emacs windows. Performance in situations when the terminal wants to spit out a lot of output leaves much to be desired, but the convenience of staying inside Emacs outweighs the drawbacks.
Another option is to run Emacs as a daemon, and then "live inside" tmux while moving between terminal-mode emacsclient , zsh/bash, etc. running in tmux sessions, windows and panes.
My personal workflow moved that direction about a year ago and I've never looked back.
I have tried. And I can't. It's just too slow when working with tons of output (which is common in my work). (term-mode is no better.)
Emacs is one of my favourite tools on a computer. I love Lisp (even Elisp, which is getting closer to Common Lisp as time goes on) and I love the interaction, but Emacs is not good for serious terminal/shell work and it, sadly, is pretty annoying as a tiling "window" manager.
Maybe with multi-threading it will get better, but until then, I can't see a compelling reason to work exclusively in Eshell.
I use ansi-term for quick tasks (e.g. re-run a build command), but you are absolutely right, if there's going to be a lot of output, I'm using my old trusty urxvt,
>Emacs is not good for serious terminal/shell work
I am interested in this aspect of Emacs (since there're very few things traditionally done by Emacs that Emacs is too slow at), but confused by your comment.
My first guess was that the tons of output take longer to get inserted into an Emacs buffer than they take to get inserted into the buffer of a good terminal-emulation application.
But surely you realize that multi-threading wouldn't help with that, hence my confusion.
Can you give an example of a program that produces too much output for Emacs to keep up with?
Does the program generating the tons of output do a lot of cursor addressing (like, e.g., the progress bar of homebrew or curl does)?
I've run into similar issues. It seems to be the draw speed that is very slow. Each 80char line takes a good 10ms to render, which when working with a fast command that outputs a lot of text... The command will have been done for thirty seconds while eshell is still sputtering along showing output.
This is especially noticible with my on-modified-run-tests script - if there is a long stack trace, often times it's faster to kill the task and start it again rather than letting it finish.
If the output is getting parsed in some way then it can get really slow. For example, automatic highlighting of matching-parenthesis is great 99% of the time, but can hang the process for several minutes on large outputs (eg. a MySQL dump of serialised PHP objects).
On a related note, the "clear" function at http://www.khngai.com/emacs/eshell.php can help speed things up when your buffer gets large; it's basically like "reset" in bash. The reason it's useful is that the shell prompts in an eshell buffer are marked as read-only, so trying to clear a region containing prompts will fail. I'm sure there are other workaround for this, but running a "clear" command is easy enough :)
> My first guess was that the tons of output take longer to get inserted into an Emacs buffer than they take to get inserted into the buffer of a good terminal-emulation application.
Correct.
> Can you give an example of a program that produces too much output for Emacs to keep up with?
Anything that produces a few hundred lines you didn't expect, e.g. a compile gone bad or an unexpectedly large diff. Unless you add something to "comint-preoutput-filter-functions" to discard output, you get to lean on C-c and wait for things to settle down.
The thing that's so annoying is that it seems to process data that it really should ignore. It has nothing to do with display at all, it's a pipe.
(I wanted to update that example with using star-prefixed grep and sort since the info manual says that should avoid emacs built-ins, but after five minutes of waiting I gave up.)
I love Lisp, and I am also quite fond of Elisp, but I am still hoping that Guile Emacs will be reality soon. I have missed a nice, well-functioning FFI in emacs once or twice, and guile would provide that.
And of course, ever since SICP I am still eagerly waiting to not ever having to program anything else than scheme.
I see two sides in shells, you want high-perf high-density UI or you want design oriented low bandwidth ones. For the former emacs is not good (I'd say it's not even lispy to witness and crunch lots of data visually, write abstractions/queries and such and think higher).
One thing I really like about Eshell is how you can make the whole buffer editable. Printed too many lines by accident? Just mark the whole region and do M-x delete-non-matching lines. Other fun things to do include using output redirection to insert text straight into buffers! One last cool thing is that Eshell comes with it's own little pseudo-devices like /dev/kill and /dev/clip, you can probably guess what they're for.
Although as awesome as it is, there are still some places where I have no choice but to use a real terminal. This is mostly curses-like interfaces and stuff.
I find it funny that the author omitted one of the biggest missing features in Eshell: input redirection, you just can't do it.
Here's further reading for anyone interested in Eshell, I think this is the most comprehensive little guide out there:
"This is mostly curses-like interfaces and stuff."
Which is, of course, a great example of the reason we need to provide as much functionality as we reasonably can outside such interfaces (including GUI interfaces).
I have tried to like it, but the lack of input redirection is just pathetic. Worse, rather than just calling a real shell when it detects attempted input redirection, it chastises you and refuses to do anything.
Plus, while Emacs' "M-x command" completion is great, Eshell was still about as good as mid-90s Bash the last time I tried it. And then there's the cost of learning yet another slightly-different shell syntax. While this could probably be done right, it hasn't been in the 10+ years of Eshell's existence, so I'm not holding my breath.
22 comments
[ 0.20 ms ] story [ 57.8 ms ] threadAlso, tab-completion seems somewhat good. I typed /u and TABbed, and got /usr/.
/usr/bin/lv gives me /usr/bin/leave on first TAB, then cycles through /usr/bin/llvm-g++, etc. on subsequent tabs.
Globbing: ls /*.js did what you'd want within a directory whose subdirectories contain a lot of .js files.
It looks like someone added completions for git (and bzr, hg, if you care): http://tsdh.wordpress.com/2013/05/31/eshell-completion-for-g... Works pretty well.
I wonder if there's a way to provide a bridge with zsh's completions, such that if you have completions for zsh, you have them for eshell.
My personal workflow moved that direction about a year ago and I've never looked back.
Emacs is one of my favourite tools on a computer. I love Lisp (even Elisp, which is getting closer to Common Lisp as time goes on) and I love the interaction, but Emacs is not good for serious terminal/shell work and it, sadly, is pretty annoying as a tiling "window" manager.
Maybe with multi-threading it will get better, but until then, I can't see a compelling reason to work exclusively in Eshell.
I am interested in this aspect of Emacs (since there're very few things traditionally done by Emacs that Emacs is too slow at), but confused by your comment.
My first guess was that the tons of output take longer to get inserted into an Emacs buffer than they take to get inserted into the buffer of a good terminal-emulation application.
But surely you realize that multi-threading wouldn't help with that, hence my confusion.
Can you give an example of a program that produces too much output for Emacs to keep up with?
Does the program generating the tons of output do a lot of cursor addressing (like, e.g., the progress bar of homebrew or curl does)?
Have you tried shell mode as well as eshell mode?
This is especially noticible with my on-modified-run-tests script - if there is a long stack trace, often times it's faster to kill the task and start it again rather than letting it finish.
On a related note, the "clear" function at http://www.khngai.com/emacs/eshell.php can help speed things up when your buffer gets large; it's basically like "reset" in bash. The reason it's useful is that the shell prompts in an eshell buffer are marked as read-only, so trying to clear a region containing prompts will fail. I'm sure there are other workaround for this, but running a "clear" command is easy enough :)
Correct.
> Can you give an example of a program that produces too much output for Emacs to keep up with?
Anything that produces a few hundred lines you didn't expect, e.g. a compile gone bad or an unexpectedly large diff. Unless you add something to "comint-preoutput-filter-functions" to discard output, you get to lean on C-c and wait for things to settle down.
Example: https://news.ycombinator.com/item?id=7310770
The thing that's so annoying is that it seems to process data that it really should ignore. It has nothing to do with display at all, it's a pipe.
(I wanted to update that example with using star-prefixed grep and sort since the info manual says that should avoid emacs built-ins, but after five minutes of waiting I gave up.)
And of course, ever since SICP I am still eagerly waiting to not ever having to program anything else than scheme.
Although as awesome as it is, there are still some places where I have no choice but to use a real terminal. This is mostly curses-like interfaces and stuff.
I find it funny that the author omitted one of the biggest missing features in Eshell: input redirection, you just can't do it.
Here's further reading for anyone interested in Eshell, I think this is the most comprehensive little guide out there:
http://www.masteringemacs.org/article/complete-guide-masteri...
Which is, of course, a great example of the reason we need to provide as much functionality as we reasonably can outside such interfaces (including GUI interfaces).
Plus, while Emacs' "M-x command" completion is great, Eshell was still about as good as mid-90s Bash the last time I tried it. And then there's the cost of learning yet another slightly-different shell syntax. While this could probably be done right, it hasn't been in the 10+ years of Eshell's existence, so I'm not holding my breath.