]> git.cworth.org Git - cworth.org/commitdiff
Fix bulletted list formatting.
authorCarl Worth <cworth@cworth.org>
Thu, 20 Aug 2009 23:34:46 +0000 (16:34 -0700)
committerCarl Worth <cworth@cworth.org>
Thu, 20 Aug 2009 23:34:46 +0000 (16:34 -0700)
MarkDown is *close* to intuitive, but apparently not perfect.

src/sup/a-mail-client-for-geeks.mdwn

index a31e0784fd97e083e7a83becad8bde7a67fd08d5..54c1e93cd4923cb856959deec8972c4d40c835af 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