Add Robert Haight as another solver

[cworth.org] / src / sup / a-mail-client-for-geeks.mdwn

diff --git a/src/sup/a-mail-client-for-geeks.mdwn b/src/sup/a-mail-client-for-geeks.mdwn
index a31e0784fd97e083e7a83becad8bde7a67fd08d5..7358f9fcde581fd80a5e35340c0d940faa53a18c 100644 (file)
--- a/src/sup/a-mail-client-for-geeks.mdwn
+++ b/src/sup/a-mail-client-for-geeks.mdwn
@@ -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:
 
 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
 
 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
 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
 
 [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
 
 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