11–20 of 23 posts
I've tried living in eshell but zsch auto complete is just too damn good. Is there really good auto completion for eshell?
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 wi…
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 wi…
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?
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 conveni…
My personal workflow moved that direction about a year ago and I've never looked back.
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'r…
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.
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 wi…
>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 mu…
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.
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 wi…
>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 mu…
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.
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 wi…
>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 mu…
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.)
Earlier quoted context omitted.
>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 mu…
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 fas…
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 :)
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 wi…
And of course, ever since SICP I am still eagerly waiting to not ever having to program anything else than scheme.