[craigching]

Yeah, as an emacs user, every time a tmux post pops up on HN, I go read about it and wonder what it would really do for me. I guess what I'm seeing is that for my emacs sessions it really doesn't buy me anything. I'd be curious to hear about things I can do with tmux that I can't do with emacsclient and emacs daemon.

[Myrmornis]

Tmux is for your shell sessions. Emacsclient is orthogonal. Or do you do all your shell work in emacs?

[craigching]

> do you do all your shell work in emacs?

I do! eshell is a very good shell that integrates nicely with emacs. For instance, I love egrep in eshell, you can move your cursor over the output and emacs will take you right to the line that matches.

So let me temper that just a wee bit, I do use eshell a lot, but there are a few cases where it doesn't work quite well, but those cases are few and far between, certainly not enough to warrant using tmux, at least I can't be convinced yet.

EDIT: I said eshell integrates nicely with emacs. That's not true, it's a shell written in elisp for emacs, no integration whatsoever. Sorry, but I don't feel like rewording what I wrote, so just adding this edit comment ;)

[unhammer]

If you do any sort of work on Middling-to-Fairly-Big Data, eshell is not for you. I love emacs, and would love to love eshell, but I prefer running grep/awk/sed/etc in tmux since it's just soo much faster.

And of course, if you need to use any sort of curses type thing, eshell (or M-x shell) often fails in ugly ways.

[craigching]

I upvoted you because I think you present a fair point, especially about "big data" and curses programs, though I recently noticed that top is behaving well in emacs and I don't think it was before, so maybe it's getting better and I need to revisit some of my old workflows to see if I can incorporate them.

As for running grep/awk/sed in tmux being fast, I don't doubt running the individual program and getting your results is faster, but the interaction in eshell and going beyond, say, grep output and actually being able to go the the line in question, the whole workflow, is much faster than running grep and then firing up an editor on the file and moving to the line. That is the real power, the whole workflow is made faster such that the fact that grep is a slow elisp implementation doesn't matter. And elisp grep really isn't that slow, accessing the file system is the slow part and that's true for both implementations and both can benefit from aggressive file caching anyway.

The less I have to leave emacs during an editing session, the faster/more productive I'll be. And that's the real power of eshell IMO.

[Myrmornis]

As an emacs user I do agree with what you're saying. I do all my codebase searching using ag from emacs[1] instead of grep and I absolutely love it: you get the results in a compilation-mode buffer which instantly jumps you to the search hits.

Maybe I should use eshell or one of the comint shells more. But I wouldn't want to leave bash/zsh behind -- I might as well be on windows then :) (which is, btw, a strong argument in favor of the workflow you're describing -- for those poor people who are forced to use windows, eshell is a blessing.)

[1] https://github.com/Wilfred/ag.el

[craigching]

Thanks for sharing about ag, I'm going to check that out! Luckily I'm on Linux for most of my development, but sometimes I am on Windows and you're right, eshell is a blessing there :)

[unhammer]

> And elisp grep really isn't that slow, accessing the file system is the slow part and that's true for both implementations and both can benefit from aggressive file caching anyway.

Sorry, I never meant elisp grep was slow. I meant _piping_ was slow.

Here's regular bash in tmux:

    $ wc -l fullform_nb.txt 
    1180517 fullform_nb.txt
    
    $ time sort fullform_nn.txt |grep åbryug
    114297  åbryug  åbryug  adj pos m/f ub eint normert     510     1
    114297  åbryug  åbryug  adj pos nøyt ub eint normert    510     4
    114297  åbryug  åbryugare       adj komp normert        510     5
    114297  åbryug  åbryugast       adj sup ub normert      510     6
    114297  åbryug  åbryugaste      adj sup bu normert      510     7
    114297  åbryug  åbryuge adj pos bu eint normert 510     3
    114297  åbryug  åbryuge adj pos fl normert      510     2
    
    real    0m2.888s
    user    0m9.570s
    sys     0m0.132s

eshell:

    $ time sort fullform_nn.txt | grep åbryug
    114297	åbryug	åbryug	adj pos m/f ub eint normert	510	1
    114297	åbryug	åbryug	adj pos nøyt ub eint normert	510	4
    114297	åbryug	åbryugare	adj komp normert	510	5
    114297	åbryug	åbryugast	adj sup ub normert	510	6
    114297	åbryug	åbryugaste	adj sup bu normert	510	7
    114297	åbryug	åbryuge	adj pos bu eint normert	510	3
    114297	åbryug	åbryuge	adj pos fl normert	510	2
    111.725 secs
    

Note: the output from grep comes after about 20 seconds, then it runs for 90 sec's until time is done. In any case, way slower than bash in tmux (which is as fast as bash outside tmux). (Silly example, but my real oneliners tend to be rather longer and more cryptic …)

And when I try to e.g. "sort -k2,2 -t$'\t' file" it gives zero results, doesn't even tell me whether $'\t' is unsupported, same deal if I try '\t', whereas in bash, if I try a plain '\t', sort at least tells me sort: multi-character tab ‘\\t’. In eshell, I might be mislead to thinking the grep gave zero results. To me, eshell is both slow and dangerous.

I'm happy eshell works for you, but it is just not usable at all for me. OTOH, I'm faster at typing alt-TAB than at C-x b esh RET, so I don't mind having to leave emacs as long as I only ever have to switch between the terminal and emacs.