Changelog
=========

0.4 - 2009-06-28
----------------

* Propogate non-zero return codes from subprocesses so that mswatch
  can know to restart things.

* Don't check if the sync fails, allows mswatch to keep trying to sync
  when offline without constantly making the checkers run

* Add another syncer for offlineimap with a local-only gnus checker

* Translate Gmail and Gnus IMAP folder separators


0.3 - 2008-05-13
----------------

* Clarify and correct documentation

0.2 - 2008-05-07
----------------

* Fix handling of site-lisp for easy_install

0.1 - 2008-05-01
----------------

* Initial release

0.0 - Backstory
---------------

It is amazing that `MUAs do indeed still suck`_.  In my case this is
exacerbated by a strong preference to use Gnus as my MUA.  Thunderbird
may be great, but since it lacks good integration with Emacs (and no,
emacsclient external editor is not enoug), it really doesn't matter.

I began by using nnimap to access dovecot on my server.  I was still a
Gnus newbie at that time and I ran into many problems with nnimap.  I
tried using the Gnus agent to address these but then my head and my
Emacs exploded in unison.

As many others have before, I moved on to sync the ~/Maildir on my
server with a full local copy using OfflineIMAP.  Then I setup gnus on
my laptop to use nnimap talking to Dovecot running locally on my
laptop.  This worked fabulously with one exception, I had to choose
between how quickly new mail would show up and how much bandwidth
OfflineIMAP would use.  I'm pretty impatient about my email, so with a
sync frequency of every minute, I found that OfflineIMAP could easily
saturate what little bandwidth was available at a cafe or somesuch.
Lengthening the frequency only improved things slightly since every 5
minutes or what have you, my web browsing would still slow to a crawl.
I assume I was also slowing down everyone else, please don't tell
them.  Still I used this approach for a year or more since I could
think of nothing better.

Time went on and I used more and more of Gnus' features.  I have a
beautiful BBDB fancy splitting setup.  I use automatic scoring which
is just a delight.  I agree that Gnus is much too hard to learn and
configure, but in all honesty, it could be even harder and I'd still
use Gnus.

Later, with much more Gnus experience under my belt, I blew away my
.emacs and .gnus.el determined to use nnimap and the agent now that I
was more proficient.  I set it all up and it all seemed to work but as
time went on I kept running into more and more problems.  Over and
over again, the Group buffer would show inaccurate counts of new
messages or not show new messages at all.  I'd find that articles
hadn't been downloaded after all so I wasn't able to read them
offline.  I came to resemble a Skinarian pigeon, genuflecting before
Gnus in the face of chaos with mysterious combinations of "C-u g" and
"M-x gnus-agent-regenerate".  In addition to those and many other
small annoyances, there was still the bandwidth vs check frequency
issue, only this time every time the mail would be checked my emacs
would block as well.

Then I learned about IMAP IDLE and was beside myself with excitement.
Then I learned that neither OfflineIMAP nor Gnus nnimap supported it
and that Thunderbird did and I found myself seriously considering
switching.  Reluctance to leave Gnus, however, kept me googling for
some time and eventually I found mswatch.  Really a trio of three
utilities, mswatch uses Linux's file modification notification system
(inotify or dnotify) to synchronize maildirs as needed.

Initially, I tried mswatch with its intended sync program, mbsync, but
mbsync cannot sync nested IMAP folders.  The author of mswatch was
kind enough to document clearly the interfaces used for the separate
processes, so I set about writing a script that wraps OfflineIMAP to
provide the mswatch interface.  For the first time, I finally had a
mail setup that delivered new mail quickly and didn't consume obscene
amounts of bandwidth.

But wait, I use Gnus splitting with BBDB, so whenever mail arrived in
the INBOX on my server, it would be synced to my laptop which Gnus
would then split into its destination and then it would be synced back
to the server.  This little dance doubles the bandwidth consumption.
Furthermore, I've always wanted my BBDB splitting to be done on my
server for those times when I use Gnus in an SSH session or when I
access my mail from another IMAP client.  So I also wanted to notify
my gnus runnong on my server when when mail arrived.

So then I set about writing a checker script that wraps the mswatch's
watcher processes and uses "emacsclient --eval" to tell Gnus to check
the folder where a change has occurred.  On my server, this means the
mail will be split before notifying the mswatch process that a change
has occurred which means that mswatch will also synchronize the folder
the message was moved to.  No more round trip.  This also has the
added benefit of keeping Gnus up to date on all of my mail folders
without having to use gnus-demon to periodically check all folders.
All in all, *much* faster, very current information, and much less
interruptions.

There are many things about this solution that are hackish and
inefficient so I'd say it's somewhere between %75 and %80 there, as it
were.  Given, however, that no previous solution has even broken %50
I'm happy as a clam for now.

.. _`MUAs do indeed still suck`: http://groups.google.com/group/linux.debian.user/msg/7594165a2b6d1c49 
