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)
-
-4. Make emacs fast for big search results (see "lazy searching" below)
-
-5. Fix Xapian defect #250 so tagging is fast.
+3. Fix Xapian defect #250 so tagging is fast.
Emacs interface (notmuch.el)
----------------------------
tables that add to it.
Add a command to archive all threads in a search view.
-
-Lazy searching: call "notmuch search" with --first and --max to fill
-just a screenful of results, and then fill in more as ther user pages
-through the buffer.
-
+
Add a '|' binding from the search view.
Add a binding to run a search from notmuch-show-mode.
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.
+
+Make failure to read a file (such as a permissions problem) a warning
+rather than an error (should be similar to the existing warning for a
+non-mail file).
+
Add support for files that are moved or deleted (which obviously need
to be handled differently).
(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).
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)
projects / notmuch / blobdiff