1 Write a "notmuch tag" command to add/remove tags from messages
2 matching a search query.
4 Rename notmuch_thread_results_t and notmuch_message_results_t to
5 notmuch_threads_t and notmuch_messages_t respectively.
7 Add a talloc context as the first argument to each command in
10 Write a "notmuch show" that displays a single thread.
12 Fix to use the *last* Message-ID header if multiple such headers are
13 encountered, (I noticed this is one thing that kept me from seeing the
14 same message-ID values as sup).
16 Audit everything for dealing with out-of-memory (and drop xutil.c).
20 Achieve 100% test coverage with the test suite.
22 Think about this race condition:
24 A client executes "notmuch search"
25 Then executes "notmuch show" on a thread
26 While user is reading, new mail is added to database for the thread
27 Client asks for the thread to be archived.
29 The bug here is that email that was never read will be
30 archived. That's bad. The fix for the above is for the client to
31 archive the individual messages already retrieved and shown, not
32 the thread. (And in fact, we don't even have functions for removing
35 But this one is harder to fix:
37 A client executes "notmuch search"
38 While user is reading, new mail is added to database for the thread
39 Client asks for a thread to be archived.
41 To support this operation, (archiving a thread without even seeing
42 the individual messages), we might need to provide a command to
43 archive a thread as a whole. The problem is actually easy to fix
44 for a persistent client. It can onto the originally retrieved
45 thread objects which can hold onto the originally retrieved
46 messages. So archiving those thread objects, (and not newly created
47 thread objects), will be safe.
49 It's harder to fix the non-persistent "notmuch" client. One
50 approach is to simply tell the user to not run "notmuch new"
51 between reading the results of "notmuch search" and executing
52 "notmuch archive-thread" (or whatever we name it).