A little more on Vim and Emacs file handling

Yesterday’s post about switching back to Emacs saw quite a few comments from people (most of them useful, even). I learned a few things.

My biggest gripe about Vim was that for the file types I worked with most, its indentation and syntax highlighting was inferior to that of Emacs. I’d like to illustrate that with an example.

Let’s consider one of those file types: XML containing DocBook markup.

Vim has a DocBook mode. It doesn’t autodetect DocBook files, so I have this at the top of each one:

<!-- vim: set filetype=docbkxml shiftwidth=2 autoindent expandtab tw=77 : -->

Now, why should Vim need a separate DocBook mode? DocBook is just XML or SGML, and these things have a well-formed nature. Well, part of the reason is that /usr/share/vim/vim71/syntax/docbk.vim has a ton of lines like this:

syn keyword docbkKeyword chapter citation citerefentry citetitle city contained

Yes, they are hard-coding all the DocBook element names into the editing mode. It’s probably used for completion, highlighting, maybe indentation. I’m not sure, really. I remember that editing these files without the DocBook mode was much more painful anyway, but that was 8 months ago and I can’t quite remember why.

Now, what about Emacs? I don’t know if Emacs even has a DocBook mode, mainly because I don’t have to care. The Emacs psgml mode actually parses the DTD for your XML or SGML files. It knows exactly what the valid tags are from doing so. This means it has full functionality not just for DocBook, but for any XML or SGML file with a DTD.

Not only that, but it knows more about the files than Vim does. For instance, both Emacs and Vim can do completion of various things. Vim </ C-x C-o (ooo, sounds like Emacs!) can complete my closing tags. But it can’t autocomplete my opening tags, and it certainly isn’t aware

Not only can Emacs autocomplete opening and closing tags, but it knows exactly what tags are valid at a given place in the document (thanks to the DTD) and will only consider those tags for completion. Moreover, depending on how you have configured it, it could also insert spots for you to add any required attributes. So, for instance, if you’re editing XHTML and autocompletion gives you an <img> tag, it would add src="" in it for you, as a reminder that src is required.

There are a host of other smart things that Emacs can do with XML or SGML documents. For instance, you can get a list of all tags valid at the current point with C-c C-t or Shift-RightClick — useful if you’ve forgotten the name of a tag for a moment.

The difference isn’t as great with everything. But it sure is noticable as I work with XML and Haskell files.

11 thoughts on “A little more on Vim and Emacs file handling

  1. Filippo Giunchedi says:

    Hi,
    you might want to have a look at zack’s [url=http://www.bononia.it/~zack/blog/posts/2007/02/dtd2vim.html]post[/url] about having dtd-aware completion for vim

  2. Emacs is scripted at a higher level. Vim sometimes feels like a collection of ad-hoc hacks. It’s more a matter of culture rather than language facilities, I think. The DTD-parsing XML mode is a good example.

    This is why I’m always surprised that in practice Vim seems to work better for editing code. Perhaps my observations are too subjective: I see coworkers who use Emacs sometimes struggling to do certain editing operations that I can do much faster in Vim. Perhaps I’m just not noticing all the things they can do much faster in Emacs? Perhaps my coworkers haven’t invested the same amount of time in mastering Emacs that I have invested in Vim?

    Vim and Emacs are not just editors, they have their own philosophies. I suspect that once you internalize one philosophy, you won’t be able to switch to a different editor. You’ll always miss the things you used to have, and not notice the things you could have. It’s like switching programming languages: it won’t work if you keep using the old idioms.

    This is not a plea for you to give Vim another try. Both Vim and Emacs are excellent editors, and it’s a good idea to pick one and master it. After that, switching is pointless. Well, unless you practice pair-programming with people who prefer the other editor, then it pays to learn at least the basics.

  3. Daniel Burrows says:

    I’ve never used psgml-mode, only nxml-mode, so I decided to give it a try after reading your plug here. Is some configuration necessary to get it working? When I loaded some DocBook and started trying to edit, it didn’t seem to recognize most tags as tags (no colorization). I typed and hit Enter, then Tab, and psgml refused to indent the contents of the paragraph (the cursor stayed put at column 0). On the other hand, the tag itself was indented beyond its context!

    Since you wrote in such glowing terms about psgml, I suspect I just did something wrong. Everything I wrote above works with nxml, at the cost of having to convert your schemas to Relax-NG (but DocBook is available by default).

    1. John Goerzen says:

      My guess would be a DTD problem. Start with it at the top-level file. psgml normally parses the DTD — and thus colorizes the buffer — the first time you press Tab. (There is a setting to make it do that automatically). You should be able to run M-x sgml-general-dtd-info and have it show something reasonable if it got the DTD parsed.

  4. brent saner says:

    i usually shut up the entire argument with “i use pico/nano”

    funny thing is i actually do (with auto-wrap turned off, obviously).

    i just really like simplicity and minimalism in my editors, it helps me focus on the text itself.

    1. John Goerzen says:

      For the minimal approach, I reach for my Smith-Corona. I suppose I could disable the margin warning bell if I needed absolutely no frills…

    2. undees says:

      I thought I was the only one who used “nano” to stop that argument! If I desperately need to edit something outside X, it’s usually a trivial change that wouldn’t benefit from all those fancy commands.

      Just give me a tiny editor whose Quit keystroke is written right there on the screen, so I don’t have to remember “!q” (or is it “q!”?). (I must have an Emacs brain; my fingers can still remember C-x C-c after months of other text editors, but I have to look up the Vim commands every time.)

    3. Matt says:

      Do you program in the untyped lambda calculus too? It’s simple. Really lets you focus on the program itself.

  5. Really, nxml is far superior to psgml … at least for xml. And nxml is about to be bundled into emacs (as soon as I get enough tuits).

    nxml doesn’t do dtd parsing, though. Instead, it works from Relax-NG. IIRC, it comes bundled with the Relax-NG schema for Docbook.

  6. I’ve been using emacs today.
    So far, here are a few observations of it compared to my normal vim work:

    1) Emacs does start noticeable slower than vim. It’s not imperceptible on my machine, but it’s certainly no problem.

    2) You are right about indentation – it really does feel like it works much better.

    1. John Goerzen says:

      I’ll be interested to see how it turns out for you. Historically, the startup time difference was much more significant than it is now. If it bugs you, there is this thing that lest you keep an emacs process running in the background like a daemon — gnuserv or something, I think.

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.