]> git.notmuchmail.org Git - notmuch/blobdiff - TODO
TODO: Remove a couple of since-completed items.
[notmuch] / TODO
diff --git a/TODO b/TODO
index c5c748f65f92f6180c8ebb9ef26bf05652a17b02..8e81b57dc683e6db28af1b6b1d65302a90c3bb27 100644 (file)
--- a/TODO
+++ b/TODO
@@ -1,5 +1,8 @@
-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.
 
@@ -7,19 +10,8 @@ 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).
 
-Think about this race condition:
+Audit everything for dealing with out-of-memory (and drop xutil.c).
 
-       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.
+Write a test suite.
 
-   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.
+Achieve 100% test coverage with the test suite.