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
original values) rather than calling GMime (which encodes) and adding
the confusing gmime-filter-headers.c code (which decodes).
+Properly handle replying to multiple messages. Currently, the JSON
+reply format only supports a single message, but the default reply
+format accepts searches returning multiple messages. The expected
+behavior of replying to multiple messages is not obvious, and there
+are multiple ideas that might make sense. Some consensus needs to be
+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.
Audit all libnotmuch entry points to ensure that all Xapian calls are
wrapped in a try/catch block.
-Fix the "count" functionality to be exact as Olly explained in IRC:
-
- ojwb> cworth: if you set the check_at_least parameter to the
- database size, get_matches_estimated() will be exact
-
Fix the threading of a message that has a References: header but no
In-Reply-To: header (see id:"87lixxnxpb.fsf@yoom.home.cworth.org").
projects / notmuch / blobdiff