]> git.notmuchmail.org Git - notmuch/blobdiff - TODO
added syntax files for search and show screens
[notmuch] / TODO
diff --git a/TODO b/TODO
index 8783ebb61be9a6f42a7407a5690e6c8edaff683c..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)
 
-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)
 ----------------------------
@@ -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.)
 
+Allow configuration for filename patterns that should be ignored when
+indexing.
+
 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).
 
@@ -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.
 
+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).
@@ -134,3 +149,50 @@ Achieve 100% test coverage with the test suite.
 
 Investigate why the notmuch database is slightly larger than the sup
 database for the same corpus of email.
+
+Xapian
+------
+Fix defect #250
+
+       replace_document should make minimal changes to database file
+       http://trac.xapian.org/ticket/250
+
+       It looks like it's going to be easy to fix. Here's the file to
+       change:
+
+               xapian-core/backends/flint/flint_database.cc
+
+       And look for:
+
+         // FIXME - in the case where there is overlap between the new
+         // termlist and the old termlist, it would be better to compare the
+         // two lists, and make the minimum set of modifications required.
+         // This would lead to smaller changesets for replication, and
+         // probably be faster overall
+
+       So I think this might be as easy as just walking over two
+       sorted lists looking for differences.
+
+       Note that this is in the currently default "flint" backend,
+       but the Xapian folks are probably more interested in fixing
+       the in-development "chert" backend. So the patch to get
+       upstreamed there will probably also fix:
+
+               xapian-core/backends/chert/chert_database.cc
+
+       (I'm hoping the fix will be the same---an identical comment
+       exists there.)
+
+       Also, if you want to experiment with the chert backend,
+       compile current Xapian source and run notmuch with
+       XAPIAN_PREFER_CHERT=1. I haven't tried that yet, but there are
+       claims that a chert database can be 40% smaller than an
+       equivalent flint database.
+
+Report this bug:
+
+       "tag:foo and tag:bar and -tag:deleted" goes insane
+
+       This seems to be triggered by a Boolean operator next to a
+       token starting with a non-word character---suddenly all the
+       Boolean operators get treated as literal tokens)