Add new "notmuch tag" command for adding/removing tags.

[notmuch] / TODO

diff --git a/TODO b/TODO
index c5c748f65f92f6180c8ebb9ef26bf05652a17b02..fa85eb7fdc8685da42e63d3dbaa203980b26cd30 100644 (file)
--- a/TODO
+++ b/TODO
@@ -1,12 +1,24 @@
 Write a "notmuch tag" command to add/remove tags from messages
 matching a search query.
 
 Write a "notmuch tag" command to add/remove tags from messages
 matching a search query.
 

+Rename notmuch_thread_results_t and notmuch_message_results_t to
+notmuch_threads_t and notmuch_messages_t respectively.
+
+Add a talloc context as the first argument to each command in
+notmuch.c.
+

 Write a "notmuch show" that displays a single thread.
 
 Fix to use the *last* Message-ID header if multiple such headers are
 encountered, (I noticed this is one thing that kept me from seeing the
 same message-ID values as sup).
 
 Write a "notmuch show" that displays a single thread.
 
 Fix to use the *last* Message-ID header if multiple such headers are
 encountered, (I noticed this is one thing that kept me from seeing the
 same message-ID values as sup).
 

+Audit everything for dealing with out-of-memory (and drop xutil.c).
+
+Write a test suite.
+
+Achieve 100% test coverage with the test suite.
+

 Think about this race condition:
 
        A client executes "notmuch search"
 Think about this race condition:
 
        A client executes "notmuch search"


@@ -15,11 +27,26 @@ Think about this race condition:
        Client asks for the thread to be archived.
 
    The bug here is that email that was never read will be
        Client asks for the thread to be archived.
 
    The bug here is that email that was never read will be

-   archived. That's bad. With the command set above, the user can
-   avoid the problem by just not running "notmuch new" while reading
-   mail, but the same problems exists with the API. One possible
-   solution would be to store an additional timestamp with each mail
-   document for the time it was added to the database. Then searches
-   could return a timestamp, and the client could pass that same
-   timestamp back to the archive command to not modify any messages
-   with a timestamp newer than what's passed.
+   archived. That's bad. The fix for the above is for the client to
+   archive the individual messages already retrieved and shown, not
+   the thread. (And in fact, we don't even have functions for removing
+   tags on threads.)
+
+   But this one is harder to fix:
+
+       A client executes "notmuch search"
+       While user is reading, new mail is added to database for the thread
+       Client asks for a thread to be archived.
+
+   To support this operation, (archiving a thread without even seeing
+   the individual messages), we might need to provide a command to
+   archive a thread as a whole. The problem is actually easy to fix
+   for a persistent client. It can onto the originally retrieved
+   thread objects which can hold onto the originally retrieved
+   messages. So archiving those thread objects, (and not newly created
+   thread objects), will be safe.
+
+   It's harder to fix the non-persistent "notmuch" client. One
+   approach is to simply tell the user to not run "notmuch new"
+   between reading the results of "notmuch search" and executing
+   "notmuch archive-thread" (or whatever we name it).