A GNU Emacs guy's challenge to vi guys

Alright, so any hacker with air in their lungs has heard of these debates where someone argues vi sucks, and someone else claims that GNU Emacs is slow or sluggish, then the vi guy says that vi is easier to use, and the GNU Emacs guy says that no, GNU Emacs is in fact easier to use. I suppose the title of this entry may even perpetuate these.
Well, let me get one thing clear… I don’t care what editor you use. Just stop bitching about how you don’t like the one I use. That is the one and only comment you’ll see to that degree for this post. Now onto something worth reading.
So, here are a list of features that I know how to do in GNU Emacs, but many of my buddies who use vi ask me how to do. My answer is usually a joking “you use GNU Emacs,” but I’m curious to see how many of these things you can actually do in vi. I’m going to focus on features specifically tailored to software development so as to avoid the “it’s too bloated” scorn of vi users. So, here’s the list of features…

  • In emacs, with tramp-mode, you can edit files remotely with a local running instance of emacs. This allows you to even compile and debug a program on the remote host, still using your local emacs session (only with ssh in tramp-mode).
  • In emacs you can manage your version control for your files from inside of the editor. Check in, diff, etc. All works.
  • In emacs, ediff is an insanely cool diffing program inside of emacs. It lets merge, diff, and diff entire directories of files.
  • In emacs, you can use a database directly from your editor. With two buffers in a split window, you can bind one buffer to your database interface buffer, and execute queries directly from one buffer to another buffer, even live SQL from inside a source file.
  • In emacs, many languages (not all; I’m talking about you, Ruby) have debuggers that are well integrated into emacs. Perl, C, Java, Python, lisp, all just a handful of such languages. Lets you control the debugger from inside emacs, not just a command-line embedded in the buffer.

Once again, this is not a flame at vi users. I’m just curious if/how you can do these things in vi so the next time I get an “how do you do that in vi?” I can answer. Please comment (politely) to this post. Thanks for spreading the knowledge.

12 Replies to “A GNU Emacs guy's challenge to vi guys”

  1. You use Emacs? OMG, VIM owns you!
    OK, I had to do that one first 🙂 I have been meaning to play more and more with Emacs because functionality in Emacs, well totally blows VIM(vi) out of the water. To me, and probably a lot of others, VIM(vi) is much easier to use. I put out a cry for help a couple of months ago on my blog and received a ton of responses. I just got annoyed due to time limitations. I am one that hates to take forever to learn something new, so I need something to make my initial couple of weeks a breeze. Good post though, and now I know who I will use locally for an Emacs mentor!

  2. I enjoy answering questions. I can play “ask the Emacs guy” if folks want, but I’m genuinely curious how many of those things you really can do in vi(m)?. If anybody knows, please do tell ^_^

  3. I’m going to be succinct here. In vim, there are faculties readily available to perform three of your points, namely the inline and robust support for revision control, diff and debugging. The other two points may be possible, but I’ve never looked into it. I won’t detail how these are performed in vim; if you’re interested, information is easily accessible via the in-editor help system.
    One thing that you must bear in mind is that vim comes from an entirely different background than does emacs. Vim was written by a systems guy, who strictly adhered to the ‘do one thing and do it well’ mantra of the UNIX world. Thus, if you want to edit files external to your machine, set up SSHFS or NTFS, both of which are much more powerful facilities than emacs tramp.
    I know how to use both editors, and regularly use the two for various purposes. For me, vim is the clear winner (for most purposes), largely because the key ‘chords’ are intuitive and I can edit, and move about within, a file much faster than I ever could in emacs. This largely has to do with the fact that most commands are a single key press. A single press may not seem much, but taking the speed with which I type, and the sheer volume of words I type per day, it very quickly adds up.
    People who engage in debates about which editor are better almost always have the following characteristics:
    1) ignorant about usage of one or the other
    2) too much time on their hands
    – John Quigley

  4. With respect to my conclusion above. Excuse me for not making this more obvious, but that was in no way directed at you or the parent post.
    It was my attempt to prevent any debate regarding which editor is better in follow-up posts.
    I’ll direct you to some vim information so that you can understand how to accomplish these things in vim. Stay tuned.
    – John Quigley

  5. You may have heard the quip, “Emacs is a nice operating system, but I prefer Linux.” All the features you mention are nice, but none of them are text editing features. Many of them are nice in an IDE, which vim isn’t. I edit remote files by mounting remote filesystems or running the editor remotely. I use revision control systems for revision controll, diff tools for diff management, database tools for database queries, debuggers for debugging, and vim for editing text. In that regard, vim isn’t a direct competitor to emacs. They’re both quite handy (I assume) for editing text. If you want your text editor to handle a lot more than editing text, emacs is probably for you.

  6. I think this comes down to what the two are supposed to be used for. Vi(m) is a pretty good text editor, emacs is an OS with a decent text editor in it. 🙂 No flames intended. It’s just that emacs is more of an IDE-like thing.

  7. 1) Editing remote files: there’s netrw (:help netrw), which you use by opening a url like :e scp://hostname/filename. I personally never use it, I find it more convenient to ssh and open the editor there. With ssh X forwarding all my vim sessions — local and remote, console and GUI — share the same X clipboard.
    2) There are plugins for CVS/SVN. I use svncommand.vim by Adam Lazur (you can find it on http://www.vm.org). It add commands like :SVNAdd, :SVNAnnotate, SVNCommit, :SVNVimDiff (my favourite). I tend to commit from a different terminal, and svn ci spawns vim with two panes: one for reviewing the whole diff, the other for typing in the commit message.
    I do not know if there’s a way to see a list of changed files, tag the ones you want to commit, and run commit on them from within vim. There may be, but I never bothered looking for it. It would be useful sometimes, though.
    3) Vim’s diff support is pretty nice (up to five windows, with synchronized scrolling, showing of diffs within each line, folding places that do not differ, editing, moving chunks left and right). :help diff. There is no support for diffing directory trees. (Or, if there is, I haven’t discovered it yet.)
    4) Using databases or other kinds of shells: no. Vim doesn’t have a good terminal emulator, and it doesn’t support embedding external programs in its buffers. You can probably write some script to emulate that, but I haven’t seen anything yet. I usually find it easier to have an xterm open next to my gvim window.
    5) Integrated debugging: I haven’t seen this working with vim yet.

  8. As others have said, none of these are “features” of text editors. They are more like plugins. Both emacs and vim have extensive plugin frameworks, and consequently all of the things you mention are doable in Vim. Just go to vim.org and search among the scripts. Here are a few examples:
    – vcscommand.vim (http://vim.sourceforge.net/scripts/script.php?script_id=90) for version control
    – clewn (http://clewn.sourceforge.net/) for integration with gdb, pida (http://pida.co.uk/) for integration with python debugger, vimDebug (http://vim.sourceforge.net/scripts/script.php?script_id=663) generic debugger integration
    – dbext (http://vim.sourceforge.net/scripts/script.php?script_id=356) db access to 10 different databases
    You get the idea.

  9. Personally, I find most of what you mention is easy to do from within emacs easier to do from outside. They’re different tools for a reason.
    However, I make an exception for if I’m editing lisp code. m-x slime is really hot.

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.