Programs that "do one thing well" are utterly useless unless you can compose them. Emacs is a tool that composes programs that do one thing well, like Bash or X.

Emacs, as has been said time and again, is not a text editor. It is, if anything, a development shell. It contains a text editing program (the default program), and that program does not manage child processes or SSH or Git.

You could also take the stance that Emacs _is_ a program that "does one thing well:" develop programs. That's the actual task of importance. Text editing is a secondary, ancillary task that owes its importance entirely to the archaic practice of representing complex interrelationships between data and operations on those data as a static linear stream of ASCII-encoded bytes.

Unfortunately, almost all programming languages are like this (hence, "languages"), but if you ever use Emacs to edit Lisp, you'll find that it's far less like text editing than it is like directly manipulating the abstract structure of the program. It does a reasonable job trying to replicate this experience in other languages, but when you have utterly inane constructions like seventeen-precedence-level infix notation, there's only so much you can do.

> Emacs is a tool that composes programs that do one thing well, like Bash or X.

or like Vim! (as in Evil)

Do one thing well does not really apply to larger user-interface applications that inherently have to aggregate lots of unrelated functionality. It applies to one-shot commands that you'd use in shell pipelines; that's why the other commandment is to use text streams. The point is that by combining these small utilities which do one thing well, you can create the aggregated functionality you need to perform a higher level task. Whereas if you didn't have these little utilities which do one thing well, you'd be scratching your head trying to figure out how to do something that a big monolithic application can do for you but which you need in a different context, i.e. where running that big monolithic application to do that one thing is very very incovenient if not impossible. Why do people quote this out of context?

If you stop and think about it, it's really pretty much impossible to define the "one thing" a code editor does.

Forcing the user build everything out of shell pipelines is not the goal, and achieves nothing. At some point, it is appropriate to build the aggregate and combine these functionalities for the user so that he doesn't have to do it himself. And in many cases, you end up reimplementing the thing because it is more efficient that way. The shell utility is still there for the user should he need it.

Displaying code and editing it are two separate things. Sounds like Vim is pretty bloated acting as both an editor and a pager.

Use ed to edit, and pick a side in the more/less wars if you want to read it.

I realize that you're joking, but... vim is a better less than less is, in almost all cases, for viewing code, because you get syntax highlighting.

I'm not a vim user, but I use it to replace less because syntax highlighting is the bee's knees: (you may need to change `vim74` to whatever it is on your system.)

  alias less='/usr/share/vim/vim74/macros/less.sh'

You can then do things like:

  less Makefile +400

which pairs very nicely with `grep -n`.

Why not just pipe pygmentize to less? That's truly embracing The Unix Way™.

  pygmentize foo.py | less -r

But ed also displays code. I think you're looking for some way of editing code without displaying it on the screen at all.

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?

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

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.

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.

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.

> Do one thing well.

For example, be an outstanding VM, IDE and a thriving ecosystem of libraries for development in a quite nice (and becoming better with each version) Lisp dialect.

Anyway, that's really a matter of preference. It's ok if you want to tell the world about yours, but try to word it in a way which isn't confrontational for people who have different preferences.

> Do one thing well.

Do you really demand that an OS should only 'do one thing well'? :ø)

Well, yes. That's what makes Unix OSes so great. Programs all the way down to the command line are separate from the OS. Modules and drivers are also semantically separate from the core.

So how would you envision that the Emacs OS should be structured/used?

Something like this:

  sudo aptitude purge emacs
  sudo apt-get install vim gvim
  gvim

Edit: Clearly I'm joking. If you wanted a serious answer, Emacs is just a large, easily extensible program. It's not really an OS. That's like saying Google Chrome (contains a package manager, web browser, text editor, scripting language, and much more) is an OS.

Chrome OS runs on a Linux kernel. Linux is the core OS for Chromebooks. Similarly, an "Emacs OS" would need a real OS underneath it.

Emeacs is an OS. It just needs its own kernel.