* some code re-arrangement: src/guile-> guile, toys/mm -> emacs

2011-12-13 08:03:19 +02:00
parent eb7bd05487
commit 8b39c69c89
31 changed files with 10 additions and 22 deletions
--- a/emacs/mm.org
+++ b/emacs/mm.org
@ -0,0 +1,38 @@
+* mm
+
+** Introduction
+
+   Welcome to *mu mail* - an emacs client for the [[http://www.djcbsoftware.nl/code/mu][mu]] maildir indexing/searching
+   tool. It turns mu into an e-mail-client.
+
+   Mu Mail has things in common with programs such as 'notmuch' and 'md', but -
+   in the opinion of it's author - it offers some unique features as
+   well. Basically, the mail handling (deleting, moving etc.) is inspired by
+   *Wanderlust* (another emacs-based e-mail client) and *dired*, while it takes
+   some cues from GMail with respect to being search-based. In practice this
+   means that mu mail provides a 'traditional' folder-based e-mail client, on
+   top of a search based back-end.
+
+** How does it work
+
+   While not necessarily interesting for all users of mu mail, for some it may
+   be interesting to know how mu mail does its job.
+
+   Since version 0.9.8, mu has a special =server= command, which drops you into
+   a command line where you can give certain commands to mu (see the =mu-server=
+   man page). While it would certainly be possible to have specific commands to
+   get lists of messages, move them, delete them etc., having a running instance
+   around gets rid of the startup time of mu and especially the message
+   database.
+
+   So, when running mu mail inside emacs, it fires up an instance of 'mu
+   server', and communicates with it as long as it runs.
+
+   mu mail shows its results only after the mu server reports their
+   completion. Still, the execution is asynchronous, so you do not need wait for
+   anything. We found that, for example, deleting messages is fast enough to
+   allow us to wait for the results. An alternative design would be to update
+   the user-interface already; so far we are quite content with the performance.
+
+   Regarding performance, showing large numbers (thousands) of message can still
+   be a bit slower than is desirable. This is an area for improvement still.