Add missing OfflineImapError import in folder/UIDMaps.py

Bug-Debian: http://bugs.debian.org/671279
Reported-by: Ansgar Burchardt <ansgar@debian.org>
Signed-off-by: Dmitrijs Ledkovs <xnox@debian.org>
Signed-off-by: Nicolas Sebrecht <nicolas.s-dev@laposte.net>
docs: split long lines (up to 80 characters)

Not everybody has a wide screen.

Signed-off-by: Nicolas Sebrecht <nicolas.s-dev@laposte.net>
IMAPlib mixin class: pass 'readonly' exception to our callers

This will allow our callers who are capable of dealing with
readonly folders to properly detect this condition and act
accordingly.

One example is Gmail's "Chats" folder that is read-only,
but contains logs of the quick chats.

Minor Changelog improvements.

Tested-by: Abdó Roig-Maranges <abdo.roig@gmail.com>
Signed-off-by: Eygene Ryabinkin <rea@codelabs.ru>
Signed-off-by: Nicolas Sebrecht <nicolas.s-dev@laposte.net>
docs: update links to the newly created github organization

Acually, these are the minimal expected changes.
More might be done and/or discussed.

Signed-off-by: Nicolas Sebrecht <nicolas.s-dev@laposte.net>
fix: createfolders setting is ignored if readonly is True

If 'readonly' is True, folders shouldn't be created (regardless of
'createfolders' option). With old behavior, instead folders were always created
when 'readonly' is True (even if 'createfolders' was also False), which is a
serious bug (offlineimap was creating folders in all read-only repositories).
'createfolders' should only play a role if 'readonly' is False, in which case
folders should only be created if 'createfolders' is True.

Submitted-by: Vladimir Nesov <robotact@gmail.com>
Signed-off-by: Nicolas Sebrecht <nicolas.s-dev@laposte.net>
Avoid trying to synchronize folders that have empty names

Hello,

I am hitting the same issue as Jes Sorensen[1], where at some point,
offlineimap 6.5.4 would error out with the message:

 Establishing connection to mail.corp.foo.com:993
 Creating new IMAP folder '/' on server RemoteFoo
 ERROR: Creating folder  on repository RemoteFoo
  Folder '/'[RemoteFoo] could not be created. Server responded:
('NO', ['CREATE failed: invalid mailbox name'])
 ERROR: Folder '/'[RemoteFoo] could not be created. Server responded:
('NO', ['CREATE failed: invalid mailbox name'])
 *** Finished account 'Foo' in 0:03

I chased it down and it looks like the issue happens when we have a
local Maildir format, subfolders and where the separator is '/'.

Since commit a279aa7 [2], it can happen that offlineimap wrongly tries
to create a folder named '/' on the remote server.

I believe the problem is that MaildirRepository._getfolders_scandir
which is supposed to scan the list of IMAP folders under a given root
folder can now return a folder that has an empty path.  A consumer of
that function then appends the IMAP folder path separator to that empty
folder name, and tries to create the resulting folder name '/' on the
server.  Oops.

The patch accompanying this message addresses the issue by ensuring that
that function never yields an empty path.

Though, in the grand scheme of things, I don't understand why the change
in [2] would be the right fix to begin with. Is that function the right
place to make nametrans related decisions?  It seems to like that
function ought to returns what it really sees on the physical Maildir
directory.

[1]: http://article.gmane.org/gmane.mail.imap.offlineimap.general/5696

[2]: commit a279aa7307ca036f93b660ade84099550ff1a4f2
     Author: Sebastian Spaeth <Sebastian@SSpaeth.de>
     Date:   Mon Sep 19 14:14:44 2011 +0200

        Maildir: Call top-level directory '', not '.'

        If nametrans translates to an empty directory we want to find the
        top-level directory by name '' and not by name '.'. This unbreaks
        nametrans rules that result in empty folder names.

        Signed-off-by: Sebastian Spaeth <Sebastian@SSpaeth.de>

And now the patch.

Signed-off-by: Nicolas Sebrecht <nicolas.s-dev@laposte.net>
Merge branch 'da/dont-sync-folders-empty-names' into pu