X-Git-Url: https://git.notmuchmail.org/git?p=notmuch;a=blobdiff_plain;f=TODO;h=68b43bc7d8f3be10171021ba0017b25a4f0d19e8;hp=fa85eb7fdc8685da42e63d3dbaa203980b26cd30;hb=f2a4c3e565511a543971da378227b8928a48ab36;hpb=38bc6ba920cba54ab21c1fc0a6bb39f2690274ae diff --git a/TODO b/TODO index fa85eb7f..68b43bc7 100644 --- a/TODO +++ b/TODO @@ -1,52 +1,59 @@ -Write a "notmuch tag" command to add/remove tags from messages -matching a search query. +Emacs interface (notmuch.el) +---------------------------- +Add support to compose a reply to the current messaage. -Rename notmuch_thread_results_t and notmuch_message_results_t to -notmuch_threads_t and notmuch_messages_t respectively. +Selectively hide bodies in notmuch-show mode. (for example, for read +messages). -Add a talloc context as the first argument to each command in -notmuch.c. +Remove "unread" tag from messages as they are read. -Write a "notmuch show" that displays a single thread. +notmuch command-line tool +------------------------- +Make "notmuch setup" not index all messages, but only what it can do +in a reasonable amount of time, (then add "notmuch index" so the user +can complete the job when convenient). + +Fix notmuch.c to call add_timestamp/get_timestamp with path names +relative to the database path. (Otherwise, moving the database to a +new directory will result in notmuch creating new timestamp documents +and leaving stale ones behind.) + +Fix notmuch.c to use a DIR prefix for directory timestamps, (the idea +being that it can then add other non-directory timestamps such as for +noting how far back in the past mail has been indexed, and whether it +needs to re-tag messages based on a theoretical "auto-tags" +configuration file). + +Make "notmuch new" notice when a mail directory has gone more than a +month without receiving new mail and use that to trigger the printing +of the note that the user might want to mark the directory read-only. + +Also make "notmuch new" optionally able to just mark those month-old +directories read-only on its own. (Could conflict with low-volume +lists such as announce lists if they are setup to deliver to their own +maildirs.) + +notmuch library +--------------- +Actually compile and install a libnotmuch shared library. 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). +Add support for the user to specify custom headers to be indexed. + +Add support for automatic tagging of new messages based on particular +search criteria, (likely using an InMemory database for the new +messages). + +General +------- 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). +Investigate why the notmuch database is slightly larger than the sup +database for the same corpus of email.