1 files changed, 31 insertions, 0 deletions
diff --git a/microposts/mu4e-gnus.org b/microposts/mu4e-gnus.org
new file mode 100644
index 0000000..f4c3ca3
--- /dev/null
+++ b/microposts/mu4e-gnus.org
@@ -0,0 +1,31 @@
+#+title: From mu4e to gnus
+#+date: <2022-01-27>
+
+mu4e is a very popular emacs email client, known for the ease of setup.
+
+However it has its problems.  The search is not very good (for example
+I had a hard time searching for patterns with special symbols like
+subjects containg the string "[gnu.org #".  The indexing is part of the
+program, which combined with its lack of concurrency, makes it rather
+tricky to schedule update its index (on a side note elfeed has a
+similar problem).  One may need to perform some hack by killing any mu
+process running in emacs in a cron script before indexing.  I had been
+doing manual indexing, and waiting for 30 seconds to index all the
+mails whenever I want to check the mailbox for update was rather
+distracting.
+
+I made the move to gnus, which did not disappoint.  Its search is more
+useful and natural - one does not have to worry about symbols.  If
+gnus is configured with an imap server program like dovecot, indexing
+becomes that program's job, which could run as a cron job without
+bothering gnus.  Since the imap server handles concurrency, one can
+even open up gnus in multiple emacs instance.  As an added benefit,
+opening mailboxes is also much faster than mu4e.
+
+As mentioned before, the popular RSS reader elfeed operates on a
+similar model as mu4e, thus lacking concurrency.  In fact, it is even
+more limited, as if one runs elfeed on two emacs, the update in one
+does not reflect on the other!  I hope there could be an emacs RSS
+reader with the simplicity of elfeed, but taking gnus approach,
+leaving fetching, indexing and storage to a (local) server program,
+while the reader itself simply acting as a local client.