[aaronem]

Emacs does a great job at that, too. (In fact, it contains a complete Javascript parser, which is invaluable to me since that's the language around which my professional life revolves.)

It also does a great job managing child processes and SSHing. (Or FTPing, or speaking whatever other protocol you need to use to access remote files.) I can't speak to it as a visual Git interface, but I don't doubt it's at least reasonably good at that, too.

"Do one thing well" is a good start, sure. But why not aspire to more?

[akerl_]

It's great to aspire to more, and that's why my system has more than one binary in $PATH. If a project wants to release an awesome $thing_doer in addition to their main tool's function, it should be a separate tool. That way I can use esshhelper and egitbrowser and eftp separately from emacs (yes, I know the names are contrived).

[jff]

Do you consider the shell an overly-featured program because you use it to copy/delete/create/link files, install packages, etc? No, because it's a tool which loads up other tools for your use, providing some conveniences like job control in the process.

Emacs provides a lisp implementation. People have used this lisp implementation to write ftp clients, web browsers, and yes even text editing functionality; you then use emacs to load some of that lisp code and execute it. I don't say the Bourne shell fails at "doing one thing well" since people write shell scripts and run them from within the shell.

[__david__]

That's how Emacs works though! There's a bunch of TeX junk in Emacs but since I never use TeX, Emacs never loads that lisp. It's just sitting around in a directory waiting in case I do need it at some point.

And Emacs has a command line for its stuff: "M-x".

And if you really want to have separate executables you can do that with small 'emacs --eval' wrappers.

[aaronem]

Different perspectives; Emacs has a built-in shell, which is closely integrated with most of the editor's functionality -- for example, Tramp, which transparently supports almost every remote access protocol in existence; if I want to copy a directory tree from host A to host B, in bash I might

    mkdir ~/tmp/foo
    scp -r user@host-a:/foo/bar/* ~/tmp/foo
    scp -r ~/tmp/foo/* user@host-b:/foo/bar
    rm -rf ~/tmp/foo

or

    ssh user@host-a 'cd /foo/bar; tar -cf - .' | ssh user@host-b 'cd /foo/bar; tar -xvf -'

while in the Emacs shell I just

    cp -r /user@host-a:/foo/bar/* /user@host-b/foo/bar

and if I want to inspect the result, in bash I

    ssh user@host-b
    ls -R /foo/bar

while in eshell I simply

    ls -R /user@host-b/foo/bar

and all the key management happens automatically, via ~/.ssh/config and ssh-agent, just as it does when I invoke OpenSSH binaries by hand.

Oh, and lest I forget, if I want to edit a remote file in Vim, I have to either ssh to that host and invoke vim there, or scp the file here and invoke local vim on it, or deal with sshfs or something -- the latter of which might seem like a perfect solution, until you consider that I use all of Linux, OS X, and Windows machines extensively in my daily life, and not all of them do sshfs well or at all. By comparison, eshell's

    find-file /user@host/foo/bar/file

is exceedingly simple, and works equally well on whatever machine I happen to be using at the moment. I don't have to worry about marshaling temp files or configurations or, indeed, anything at all; Emacs does all of that for me, quietly, in the background, so that I can spend all my time and mental effort on the changes I actually want to make, instead of doing a bunch of annoying sysadmin work just so that I can make them at all.

There's value in having lots of loosely coupled tools, but it's not the only paradigm worth considering. There's also value in a single, unified interface to an enormous range of tightly integrated functionality; indeed, I've found the result to be something of a combinatorial explosion of productivity.