notmuch setup/new: Print progress once per second instead of after 1000 files.

[notmuch] / TODO

diff --git a/TODO b/TODO
index 7ca07704b408472a79ce4b14255e893247190e25..51a5b9c1c484091c4d62981c527fad359aa02c65 100644 (file)
--- a/TODO
+++ b/TODO
@@ -1,5 +1,15 @@
-Write a "notmuch tag" command to add/remove tags from messages
-matching a search query.
+Add back full-text indexing, (see last version of
+notmuch-index-message.c in the archives).
+
+Investigate using just a simple hash while constructing threads during
+"notmuch setup", then just writing out to Xapian in one shot at the
+end without haivng to rewrite documents nor look anything up.
+
+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,34 +17,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:
-
-       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).
+Audit everything for dealing with out-of-memory (and drop xutil.c).
+
+Write a test suite.
+
+Achieve 100% test coverage with the test suite.