X-Git-Url: https://git.notmuchmail.org/git?p=notmuch;a=blobdiff_plain;f=TODO;h=ea6c3c28f57e48d1f132764fa839d9aed5d94ab3;hp=fa85eb7fdc8685da42e63d3dbaa203980b26cd30;hb=637f99d8f3f45867d0a856503f9f302333824c07;hpb=38bc6ba920cba54ab21c1fc0a6bb39f2690274ae diff --git a/TODO b/TODO index fa85eb7f..ea6c3c28 100644 --- a/TODO +++ b/TODO @@ -1,52 +1,74 @@ -Write a "notmuch tag" command to add/remove tags from messages -matching a search query. +Emacs interface (notmuch.el) +---------------------------- -Rename notmuch_thread_results_t and notmuch_message_results_t to -notmuch_threads_t and notmuch_messages_t respectively. +Portability +----------- +Fix configure script to test each compiler warning we want to use. -Add a talloc context as the first argument to each command in -notmuch.c. +Implement strndup locally (or call talloc_strndup instead). -Write a "notmuch show" that displays a single thread. +Implement getline locally, (look at gnulib). + +Completion +---------- +Fix bash completion to complete multiple search options (both --first +and *then* --max-threads), and also complete value for --sort= +(oldest-first or newest-first). + +notmuch command-line tool +------------------------- +Give "notmuch restore" some progress indicator. Until we get the +Xapian bugs fixed that are making this operation slow, we really need +to let the user know that things are still moving. + +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.) + +Ensure that "notmuch new" is sane if its first, giant indexing session +gets interrupted, (that is, ensure that any results indexed so far are +flushed). + +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 +--------------- +Add support for files that are moved or deleted (which obviously need +to be handled differently). + +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.