thread: Removed unsed sort argument from _thread_add_matched_message

[notmuch] / TODO

diff --git a/TODO b/TODO
index 8dd0878034734aa1765ae0d2163114d412b24d54..8312db106c849ef28684190353e8805be133ec4d 100644 (file)
--- a/TODO
+++ b/TODO
@@ -36,6 +36,26 @@ Fix i-search to open up invisible citations as necessary.
 Make '=' count from the end rather than from the beginning if more
 than half-way through the buffer.
 
+Fix to automatically wrap long headers (for RFC compliance) before
+sending. This should probably just be fixed in message-mode itself,
+(but perhaps we can have a notmuch-message-mode that layers this on
+top).
+
+Implement Fcc and use it for all messages, (whether a new composition,
+a reply, or a forward). This again may require a notmuch-message-mode
+that extends message-mode.
+
+Stop hiding the headers so much in the thread-view mode.
+
+Allow opening a message in thread-view mode by clicking on either
+line.
+
+Automatically open a message when navigating to it with N or P.
+
+Change 'a' command in thread-view mode to only archive open messages.
+
+Add a binding to open all closed messages.
+
 Emacs saved-search interface
 ----------------------------
 Here's a proposal Carl wrote (id:87einafy4u.fsf@yoom.home.cworth.org):
@@ -128,6 +148,20 @@ provide more MIME-structure information in its output first).
 Replace the "notmuch search-tags" command with "notmuch search
 --output=tags".
 
+Fix to avoid this ugly message:
+
+       (process:17197): gmime-CRITICAL **: g_mime_message_get_mime_part: assertion `GMIME_IS_MESSAGE (message)' failed
+       Warning: Not indexing empty mime part.
+
+  This probably means adding a test case to generate that message,
+  filing an upstream bug against GMime, and then silencing the
+  notmuch-generated portion of the warning (so that once GMime is
+  fixed, this is all silent).
+
+Simplify notmuch-reply to simply print the headers (we have the
+original values) rather than calling GMime (which encodes) and adding
+the confusing gmime-filter-headers.c code (which decodes).
+
 notmuch library
 ---------------
 Add an interface to accept a "key" and a byte stream, rather than a
@@ -185,6 +219,38 @@ notmuch searches. Here was one proposal made in IRC:
 Provide a ~me Xapian synonym for all of the user's configured email
 addresses.
 
+Add symbol hiding so that we don't risk leaking any private symbols
+into the shared-library interface.
+
+Audit all libnotmuch entry points to ensure that all Xapian calls are
+wrapped in a try/catch block.
+
+Search syntax
+-------------
+Implement support for "tag:*" to expand to all tags.
+
+Fix "notmuch search to:" to be less confusing. Many users expect this
+to search for all messages with a To: header, but it instead searches
+for all messages with the word "to". If we don't provide the first
+behavior, perhaps we should exit on an error when a configured prefix
+is provided with no value?
+
+Support "*" in all cases and not just as a special case. That is, "* "
+should also work, as well as "* and tag:inbox".
+
+Implement a syntax for requesting set-theoertic operations on results
+of multiple searches. For example, I would like to do:
+
+       "tag:inbox" SET-SUBTRACT "tag:muted"
+
+    as well as:
+
+       "tag:notmuch and <date-range>" SET-INTERSECT
+       "tag:notmuch and not (tag:merged or tag:postponed)"
+
+    See id:3wdpr282yz2.fsf@testarossa.amd.com for more details on the
+    use cases of the above.
+
 Database changes
 ----------------
 Store a reference term for every message-id that appears in