On Sat, 20 Feb 2010 16:05:35 -0500, Jameson Rollins <jrollins@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.