Emacs doesn't recognize "utf8" as a valid coding system. The correct
name is "utf-8". This is in line with the UTF-8 FAQ:

  http://www.cl.cam.ac.uk/~mgk25/unicode.html#utf-8

  The official name and spelling of this encoding is UTF-8, where UTF
  stands for UCS Transformation Format. Please do not write UTF-8 in
  any documentation text in other ways (such as utf8 or UTF_8), unless
  of course you refer to a variable name and not the encoding itself.

Using "-*- encoding:utf-8 -*-" doesn't really set the file encoding
for Emacs. It will even prompt the user when opening a compiled file:

  The local variables list in foo.mak.py
  contains values that may not be safe (*).

  Do you want to apply it?  You can type
  y  -- to apply the local variables list.
  n  -- to ignore the local variables list.

  !  -- to apply the local variables list, and permanently mark these
        values (*) as safe (in the future, they will be set automatically.)

    * encoding: utf-8

The problem is that Emacs looks for a file variable named "coding" and
it doesn't know about "encoding":

  http://www.gnu.org/software/emacs/manual/html_node/emacs/Specify-Coding.html

This is no doubt why Python recognizes "coding:" by itself:

  http://www.python.org/dev/peps/pep-0263/

This change makes the code generator output "# -*- coding:%s -*-" and
updates the documentation and examples to match this style.

- guess this is 0.9.0

- add more of a test

Without this change, when running setup.py extract_messages, we would get
error:

    TokenError: ('EOF in multi-line statement', (2, 0))

Looking at the unit test, it seems like a literal string argument in the form
of "_('xxx')" is supposed to be picked up by Babel. However, that contradicts
with the documentation, which states:

> When using tags, the values of the arguments are taken as literal strings by
> default. To embed Python expressions as arguments, use the embedded
> expression format

So, as a side effect of this commit, the convenience of "_('xxx')" has been
removed. Probably can add it back if necessary for backward compatibility.

having some weird unicode issues I can't debug; the meaning of
str.encode() seems to be changing globally somehow

  from having a url that normalizes to relative outside
  of the root.   That is, if the Lookup is based
  at /home/mytemplates, an include that would place
  the ultimate template at
  /home/mytemplates/../some_other_directory,
  i.e. outside of /home/mytemplates,
  is disallowed.   This usage was never intended
  despite the lack of an explicit check.
  The main issue this causes
  is that module files can be written outside
  of the module root (or raise an error, if file perms aren't
  set up), and can also lead to the same template being
  cached in the lookup under multiple, relative roots.
  TemplateLookup instead has always supported multiple
  file roots for this purpose.
  [ticket:174]

  [ticket:169]

  such that if no traceback is passed
  and sys.exc_info() has been reset,
  the formatter just returns blank
  for the "traceback" portion.
  [ticket:135]
- some long line cleanup

- Python 3 support is added ! See README.py3k
  for installation and testing notes.
  [ticket:119]

HTML file writing, consistently cleanup the modules/cache directories, use
nose skiptests for unsupported features.

o update the babelplugin test for babel 0.9