/xmledit

A filetype plugin for VIM to help edit XML files

Primary LanguageVim Script

xml-plugin

Maintainer: Devin Weaver suki@tritarget.org
Source: http://github.com/sukima/xmledit
Homepage: http://www.vim.org/scripts/script.php?script_id=301
Version: 1.10.5

Build Status

XML Edit is a file type plugin to help edit XML documents. It includes tag completion and tag jumping.

Licence

This program is free software; you can redistribute it and/or modify it under the terms of the GNU General Public License.
See http://www.gnu.org/copyleft/gpl.txt

Description

This script provides some convenience when editing XML (and some SGML including HTML) formated documents. It allows you to jump to the beginning or end of the tag block your cursor is in. % will jump between < and > within the tag your cursor is in. When in insert mode and you finish a tag (pressing >) the tag will be completed. If you press > twice it will complete the tag and place the cursor in the middle of the tags on it's own line.

Install

xmledit can be installed using a xmledit.vba file or using Pathogen.

Installation using xmledit.vba

First you need a xmledit.vba vimball. You can create one following the instruction in the Build section.

If you do not have VIM version 7.0 or higher this will not work. Either upgrade or deal with the shaddy old plugin which you can get at http://github.com/sukima/xmledit/tree/v1.84. (Alternativly you could manually copy the files to there proper locations however older versions of VIM will not be supported in future development)

To install the created package open the vba file in vim and source it:

$ vim xmledit.vba
:so %

If you are installing this from the source (you don't have a .vba file) you can skip the building of one by running the Makefile:

$ make install

Now read doc/xml-plugin.txt or type :help xml-plugin.txt in VIM.

Installation for Pathogen

To use xmledit in combination with Pathogen you need to place the sources in the bundle directory. This can easily be done by cloning the git repository.

$ git clone https://github.com/sukima/xmledit.git ~/.vim/bundle/xmledit

Instead of cloning you can use git submodules.

Do not use the xmledit.vba file with pathogen.

Build

Run the Makefile to build the vba file.

$ make

Now send it to all your friends.

Testing

The test environment is in the tests directory. It uses RSpec and vimrunner. Execute the test suite:

$ bundle install
$ rake

More information about testing in vim can be found at this blog post.

Using With Other File Types

This can be used with other file types besides XML. There are two ways to accomplish this. The plugin can be used as is for other languages or with extra features that are language specific via the callback method.

The first method is simply to copy xml.vim or symbolically (or hard) link it to the new file type. For example:

ftplugin/
|-xml.vim
|-php.vim -> xml.vim
`-xhtml.vim -> xml.vim

The second method expands on the idea of copying. It uses a callback method which can extend the functionality of the tags for that language. For example in an HTML document you might prefer your table tags to look like this:

<table cellpadding="0" cellspacing="0" border="0">
</table>

But by just linking html.vim to xml.vim you would have to type all that in every time. The callback could allow you to type just <table> and it would add the cellpadding=... attributes for you. The example in the documentation (:help xml-plugin-callbacks) shows how to do this with HTML files.

Caveats

There are conflicts with the AutoComplPop script. If you get errors, add the following to your .vimrc as suggested by @othree in issue #15:

autocmd FileType xml set omnifunc=xmlcomplete#CompleteTags noci
autocmd FileType html set omnifunc=htmlcomplete#CompleteTags noci

How to contribute

Individuals making significant and valuable contributions are given commit-access to the project to contribute as they see fit. This project is more like an open wiki than a standard guarded open source project.

Rules

There are a few basic ground-rules for contributors:

  1. No --force pushes or modifying the Git history in any way.
  2. Non-master branches ought to be used for ongoing work.
  3. External API changes and significant modifications ought to be subject to an internal pull-request to solicit feedback from other contributors.
  4. Internal pull-requests to solicit feedback are encouraged for any other non-trivial contribution but left to the discretion of the contributor.
  5. Contributors should attempt to adhere to the prevailing code-style.

Releases

Declaring formal releases remains the prerogative of the project maintainer.

Changes to this arrangement

This is an experiment and feedback is welcome! This document may also be subject to pull-requests or changes by contributors where you believe you have something valuable to add or change.

I am in need of unit tests. Anyone interested in helping please fork and add to the tests/spec/ directory.

Credits