]> git.cworth.org Git - cworth.org/blobdiff - src/sup/a-mail-client-for-geeks.mdwn
Add Robert Haight as another solver
[cworth.org] / src / sup / a-mail-client-for-geeks.mdwn
index a31e0784fd97e083e7a83becad8bde7a67fd08d5..7358f9fcde581fd80a5e35340c0d940faa53a18c 100644 (file)
@@ -39,37 +39,37 @@ interesting conversation with Jamey Sharp about what the ideal
 mail-handling system would look like. Here are some of the ideas we
 came up with:
 
   * Program presents me with messages that need my attention, (a
-      chronological sort of the archive with unread items in bold does
-      not count).
-
   * When I decide a message does not need my attention I can make it
-      "go away" into the archive, (and "mark as read" does not
-      count---I want to file away messages but still track whether
-      they are read or not in the archive).
-
   * Threads must be first-level objects, (in particular I want a
-      kill-thread command that archives not only the current messages,
-      but all future messages received in a given thread).
-
   * System should support arbitrary tags on messages. Tags can be
-      applied automatically, (such as applying categories to mail
-      received on lists), and applied ad-hoc by the user.
-
   * System should allow searching over the entire archive with most
-      recent results appearing instantly. Search terms can include
-      tags, message headers, or full-body search (including phrases).
-
   * In addition to full-archive search, incremental refinement
-      should be possible, (a new search based on the results of a
-      previous search).
-
   * There's no need for folders in this system. Tags and
-      incrementally refined, tag-based searching provide all the
-      benefits, (without the bug in folder-based systems where a user
-      has to hunt among many folders to find one where a search
-      returns non-empty results). In particular, the "inbox" view
-      should just be a search for unread and non-archived messages.
+ * Program presents me with messages that need my attention, (a
+   chronological sort of the archive with unread items in bold does
+   not count).
+
+ * When I decide a message does not need my attention I can make it
+   "go away" into the archive, (and "mark as read" does not
+   count---I want to file away messages but still track whether
+   they are read or not in the archive).
+
+ * Threads must be first-level objects, (in particular I want a
+   kill-thread command that archives not only the current messages,
+   but all future messages received in a given thread).
+
+ * System should support arbitrary tags on messages. Tags can be
+   applied automatically, (such as applying categories to mail
+   received on lists), and applied ad-hoc by the user.
+
+ * System should allow searching over the entire archive with most
+   recent results appearing instantly. Search terms can include
+   tags, message headers, or full-body search (including phrases).
+
+ * In addition to full-archive search, incremental refinement
+   should be possible, (a new search based on the results of a
+   previous search).
+
+ * There's no need for folders in this system. Tags and
+   incrementally refined, tag-based searching provide all the
+   benefits, (without the bug in folder-based systems where a user
+   has to hunt among many folders to find one where a search
+   returns non-empty results). In particular, the "inbox" view
+   should just be a search for unread and non-archived messages.
 
 That was basically our list of core features. Beyond that, we also
 discussed some further ideas for improving the prioritization of email
@@ -89,13 +89,20 @@ the learning-based approaches).
 It also does a few things I hadn't specified, such as displaying email
 in a full-thread nested view, (rather than one message at a time),
 with quoted elements and signatures folded out of view until the user
-asks to see them.
+asks to see them. Another nice touch is that the single-line
+presentation of a thread includes the first names of participants in
+the thread, (with bold names to indicate unread messages). This
+provides some of the essential information needed for applying Joey
+Hess's [thread
+patterns](http://joey.kitenet.net/blog/entry/thread_patterns/), but
+without the tree view at this point.
 
 [Note: I have been told that several of the above features are also
 implemented in gmail. I've never tried gmail myself, since it fails to
-provide some even more fundamental features: 1. offline usage,
-2. personal ownership of email storage, 3. free-software
-implementation for customization.
+provide some even more fundamental features: 1. <del>offline
+usage</del>, (thanks to both Mark and Greg for pointing out that gmail
+has offline support in beta via gears) 2. personal ownership of email
+storage, 3. free-software implementation for customization.]
 
 In the few days I've been using sup, it's definitely transformed the
 way I process mail. Keeping my inbox empty is simple now, and I now