Hacker News new | ask | show | jobs
by akerl_ 4341 days ago
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).
3 comments
jff 4341 days ago
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.

link
__david__ 4341 days ago
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.

link
aaronem 4340 days ago
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.

link