notmuch.el: Exceute "notmuch search" asynchronously.

[notmuch] / TODO

diff --git a/TODO b/TODO
index b85d33102f17e5d0fe536696acd62e325181121a..da8f7c9ba02775f47846d29cbb6fbe67adac7fe3 100644 (file)
--- a/TODO
+++ b/TODO
@@ -4,11 +4,9 @@ Fix the things that are causing the most pain to new users
 
 2. Allow an easy way to get tags from directory names (if the user has them)
 
 
 2. Allow an easy way to get tags from directory names (if the user has them)
 

-3. Allow an easy way to remove excess tags, (date-based search)
+3. Make emacs fast for big search results (see "lazy searching" below)

 
 

-4. Make emacs fast for big search results (see "lazy searching" below)
-
-5. Fix Xapian defect #250 so tagging is fast.
+4. Fix Xapian defect #250 so tagging is fast.

 
 Emacs interface (notmuch.el)
 ----------------------------
 
 Emacs interface (notmuch.el)
 ----------------------------


@@ -107,8 +105,20 @@ 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.)
 
 lists such as announce lists if they are setup to deliver to their own
 maildirs.)
 

+Allow configuration for filename patterns that should be ignored when
+indexing.
+

 notmuch library
 ---------------
 notmuch library
 ---------------

+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 enpoint be implicit. Second we'de 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
+own parser for the query string rather than using Xapian's QueryParser
+class.
+

 Add support for files that are moved or deleted (which obviously need
 to be handled differently).
 
 Add support for files that are moved or deleted (which obviously need
 to be handled differently).
 


@@ -124,6 +134,11 @@ Add support for configuring "virtual tags" which are a tuple of
 (tag-name, search-specification). The database is responsible for
 ensuring that the virtual tag is always consistent.
 
 (tag-name, search-specification). The database is responsible for
 ensuring that the virtual tag is always consistent.
 

+Think about optimizing chunked searches (max-threads > 0) to avoid
+repeating work. That would be saving state from the previous chunk and
+reusing it if the next search is the next chunk with the same search
+string.
+

 General
 -------
 Audit everything for dealing with out-of-memory (and drop xutil.c).
 General
 -------
 Audit everything for dealing with out-of-memory (and drop xutil.c).