X-Git-Url: https://git.notmuchmail.org/git?p=notmuch;a=blobdiff_plain;f=TODO;h=fa85eb7fdc8685da42e63d3dbaa203980b26cd30;hp=baec040d2d5b1660ce6015b89743959deb4fb8c6;hb=88bf876bae79cbaee50c62664bc1baac5cb79742;hpb=31db02a8c1afdb025da6e0e7e62630ffffc69eb7

diff --git a/TODO b/TODO
index baec040d..fa85eb7f 100644
--- a/TODO
+++ b/TODO
@@ -1,5 +1,52 @@
+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).
+
+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"
+	Then executes "notmuch show" on a thread
+	While user is reading, new mail is added to database for the thread
+	Client asks for the thread to be archived.
+
+   The bug here is that email that was never read will be
+   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).