result.) This may require removing the outer array from the current
"notmuch search --format=json" results.
-Fix '*' to work by simply calling '+' or '-' on a region consisting of
-the entire buffer, (this would avoid one race condition---while still
-leaving other race conditions---but could also potentially make '*' a
-very expensive operation).
-
Add a global keybinding table for notmuch, and then view-specific
tables that add to it.
by default, (unless the user asks explicitly for deleted messages in
the search query).
-Add keybindings for next/previous thread.
-
Add support to "mute" a thread (add a "muted" tag and then don't
display threads in searches by default where any message of the thread
has the "muted" tag).
Change 'a' command in thread-view mode to only archive open messages.
-Add a binding to open all closed messages.
-
-Change the 'a'rchive command in the thread view to only archive open
-messages.
-
-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
-------------------------
Add support to "notmuch search" and "notmuch show" to allow for
Message-ID). I'm not sure what the option should be named. Perhaps
--with-duplicates ?
-Add a -0 option to "notmuch search" so that one can safely deal with
-any filename with:
-
- notmuch search --output=files -0 <terms> | xargs -0 <command>
-
-"notmuch setup" should use realpath() before replacing the
-configuration file. The ensures that the final target file of any
-intermediate symbolic links is what is actually replaced, (rather than
-any symbolic link).
-
Replace "notmuch reply" with "notmuch compose --reply <search-terms>".
This would enable a plain "notmuch compose" to be used to construct an
initial message, (which would then have the properly configured name
"notmuch compose --from <something>" to support getting at alternate
email addresses.
-Fix the --format=json option to not imply --entire-thread.
-
Implement "notmuch search --exclude-threads=<search-terms>" to allow
for excluding muted threads, (and any other negative, thread-based
filtering that the user wants to do).
dump" does, rather than doing N searches into the database, each
matching 1/N messages.
-Add a "-f <filename>" option to select an alternate configuration
-file.
-
Allow configuration for filename patterns that should be ignored when
indexing.
-Replace the "notmuch part --part=id" command with "notmuch show
---part=id", (David Edmondson wants to rewrite some of "notmuch show" to
-provide more MIME-structure information in its output first).
-
-Replace the "notmuch search-tags" command with "notmuch search
---output=tags".
-
Fix to avoid this ugly message:
(process:17197): gmime-CRITICAL **: g_mime_message_get_mime_part: assertion `GMIME_IS_MESSAGE (message)' failed
reached on this issue, and then both reply formats should be updated
to be consistent.
+Return docid-based queries in thread search results, instead of
+message-id-based queries. These are much more compact and much faster
+to later query. This will require support from the library, both for
+retrieving docids (probably as an opaque "get a query that identifies
+this message") and for docid queries.
+
notmuch library
---------------
Add support for custom flag<->tag mappings. In the notmuch
Add an interface to accept a "key" and a byte stream, rather than a
filename.
-Provide a sane syntax for date ranges. First, we don't want to require
-both endpoints to be specified. For example it would be nice to be
-able to say things like "since:2009-01-1" or "until:2009-01-1" and
-have the other endpoint be implicit. Second we'd like to support
-relative specifications of time such as "since:'2 months ago'". To do
-any of this we're probably going to need to break down an write our
+Improve syntax for date ranges queries. date:expr should be
+interpreted as date:expr..expr so that, for example, "date:2013-01-22"
+would cover the whole of the specified day (currently that's not even
+recognized as a date range expression). It might be nice to be able to
+use things like "since:2013-01-22" and "until:2013-01-22" as synonyms
+to "date:2013-01-22.." and "date:..2013-01-22", respectively. To do
+any of this we're probably going to need to break down and write our
own parser for the query string rather than using Xapian's QueryParser
class.