On Sat, 20 Feb 2010 16:05:35 -0500, Jameson Rollins
Hey, Carl. I've noticed that you've been applying some patches that
were recently sent to the list, out of order from the chronological
queue of patches that were sent to the list. I'm a fan of the recently
applied patches, but I'm curious about what your plans are for the older
patches in the quene. Are you still planning on processing them?
Should the older patches be rebased against the current master and
Thanks for asking, Jamie.
I'm still planning on processing the entire queue, (and chronologically),
but I'm definitely capable of being influenced to grab stuff from the
I'm not at all trying to be pushy; there's just some older stuff in the
queue that I would really like to see applied, such as folder-based
tagging, json output, and some of the emacs UI improvements.
You're not being pushy at all. Please feel free to let me know what you
think is most important.
I totally agree on the things mentioned above as being priority. I want
folder-based tagging myself, and there are a *lot* of interesting things
that are blocking on json output. Meanwhile, shortcomings in the emacs
UI are causing me problems on a constant basis, (the latest thing
driving me crazy is the regression that refreshing search results makes
the current position in the search results get lost).
For folder-based tagging, that will cause an increment in the
database-format version, so I'd like to do a couple of other things at
the same time. One is to enable indexing of additional headers, (spam
flags, and mailing-list headers), and the other is to stop doing
redundant indexing of data under multiple prefixes[*].
For the emacs UI improvements, I do plan on making an early sweep of the
patch queue and applying them, (if only because I have some improvements
I need to make myself, and I want to avoid doing anything that's already
Thanks for your input, and please feel free to let me know your thoughts
at any time.
[*] This idea came from an equivalent fix recently made to sup. We are
currently indexing the subject, for example, with a subject: prefix
and also with no prefix, (to match search terms with no prefix). The fix
is to just index it with the subject: prefix, but then at search time
to take any un-prefixed terms and match them against a whole list of
prefixes, (subject:, from:, to:, etc.). This should be a nice savings on
our database size with no appreciable performance cost.
Description: PGP signature
notmuch mailing list