[GeoffWozniak]

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.

[hollerith]

>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)?

Have you tried shell mode as well as eshell mode?

[username223]

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

[warfangle]

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.

[chriswarbo]

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 :)

[warfangle]

Nah, no automatic highlighting or anything of that sort - just the raw, default, eshell.

[unhammer]

> Can you give an example of a program that produces too much output for Emacs to keep up with?

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

[dfan]

Yeah, I am a big fan of eshell in general but too much of the time I want to do a lot of I/O, at which it is dog slow.

[gnuvince]

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,

[Johnny_Brahms]

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.

[agumonkey]

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