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