Vim is [can be] a terminal-based text editor. The claim here is that emacs is big, ugly, and slow and vim is smaller & faster.
Ahem.
Not to start any flame wars, but Emacs can be run inside a terminal as well. As a matter of fact, that's the only way I run it.
"Ugly" is a matter of opinion for sure, as beauty lies in the eye of the beholder. Emacs can (and does) make use of terminal colors, fonts are freely configurable. I can't think of anything else that would be relevant for a text editor, except of course if by "ugly" you refer to its architecture, editing model, or something like that, rather than its appearance. If not, Emacs 24 allows you to install your favorite color scheme (solarized, zenburn, dawn, etc.) right through the built-in package manager.
Re: "fast" - Emacs does not show any perceivable lag in everyday use, and my main computer these days is an old netbook. Still, Emacs feels fully reactive. If you refer, however, to startup times, then you may not be aware of the 'emacsclient' feature, which is the way a lot of serious Emacs users run their editor. You basically start an emacs daemon to which you then connect with thin interface clients, but I don't even feel the need for it, possibly because the usage model for Emacs is different from Vim: I usually open one editor window on a dedicated virtual desktop that stays open all the time, and where I live most of the time, while with Vim, people tend to quickly open a couple of instances in parallel. (Maybe these patterns have established themselves in the olden times where Vim clearly outpaced Emacs in terms of startup times, i.e., on older machines, and before 'emacsclient'.)
But you're certainly right about "smaller". As I said, I'm using an old netbook most of the time, but even on this limited machine, Emacs does not take up considerable disk space. Times have changed, and disks have grown. As for RAM, I've never noticed it, the hogs are usually others (I'm looking at you, Firefox!).
Vim is nice and small that you can install it even on very limited disk space, say on your stone-old mobile phone. (Enjoy using it there, too.) But that's not a typical scenario any more, diskspace is not longer an issue in modern computing, at least as long as we're talking about text editing..
I would still say that Vim has one great advantage over Emacs, namely that it is pretty much ubiquitous. You can log in to pretty much any server, and you can be quite sure that there's some variety of vi installed. That's really great. But if that was something the author of the original post referred to with his "analogy" is questionable.
Long-time emacs user here ... I was trying to explain the context of the quote. I used "The claim here" to avoid making the statement myself and simply explain the comparison.
Comments
> What's wrong with [Tcl/Tk]?
Not speaking for the author, but Tcl/Tk apps tend to be ugly. I use gitk from time to time, but it's ugly and has some usability problems.
> Not sure I can follow?!
Mutt is a terminal-based MUA. Where Outlook is a giant monstrosity of a mail client, mutt is fast and tiny.
Vim is [can be] a terminal-based text editor. The claim here is that emacs is big, ugly, and slow and vim is smaller & faster.
w3m is a terminal-based browser. In comparison, firefox is a slow, giant, memory sucking graphical browser.
Vim is [can be] a terminal-based text editor. The claim here is that emacs is big, ugly, and slow and vim is smaller & faster.
Ahem.
Not to start any flame wars, but Emacs can be run inside a terminal as well. As a matter of fact, that's the only way I run it.
"Ugly" is a matter of opinion for sure, as beauty lies in the eye of the beholder. Emacs can (and does) make use of terminal colors, fonts are freely configurable. I can't think of anything else that would be relevant for a text editor, except of course if by "ugly" you refer to its architecture, editing model, or something like that, rather than its appearance. If not, Emacs 24 allows you to install your favorite color scheme (solarized, zenburn, dawn, etc.) right through the built-in package manager.
Re: "fast" - Emacs does not show any perceivable lag in everyday use, and my main computer these days is an old netbook. Still, Emacs feels fully reactive. If you refer, however, to startup times, then you may not be aware of the 'emacsclient' feature, which is the way a lot of serious Emacs users run their editor. You basically start an emacs daemon to which you then connect with thin interface clients, but I don't even feel the need for it, possibly because the usage model for Emacs is different from Vim: I usually open one editor window on a dedicated virtual desktop that stays open all the time, and where I live most of the time, while with Vim, people tend to quickly open a couple of instances in parallel. (Maybe these patterns have established themselves in the olden times where Vim clearly outpaced Emacs in terms of startup times, i.e., on older machines, and before 'emacsclient'.)
But you're certainly right about "smaller". As I said, I'm using an old netbook most of the time, but even on this limited machine, Emacs does not take up considerable disk space. Times have changed, and disks have grown. As for RAM, I've never noticed it, the hogs are usually others (I'm looking at you, Firefox!).
Vim is nice and small that you can install it even on very limited disk space, say on your stone-old mobile phone. (Enjoy using it there, too.) But that's not a typical scenario any more, diskspace is not longer an issue in modern computing, at least as long as we're talking about text editing..
I would still say that Vim has one great advantage over Emacs, namely that it is pretty much ubiquitous. You can log in to pretty much any server, and you can be quite sure that there's some variety of vi installed. That's really great. But if that was something the author of the original post referred to with his "analogy" is questionable.
That's why I wasn't sure I could follow :-)
:)
Long-time emacs user here ... I was trying to explain the context of the quote. I used "The claim here" to avoid making the statement myself and simply explain the comparison.