On Sat, 20 Feb 2010 16:05:35 -0500, Jameson Rollins <jrollins at finestructure.net> wrote: > 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 > resent?
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 "future" > 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 been done). Thanks for your input, and please feel free to let me know your thoughts at any time. -Carl [*] 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. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: <http://notmuchmail.org/pipermail/notmuch/attachments/20100222/63eb9098/attachment.pgp>