On Sat, 21 May 2011 19:50:37 +0100, Patrick Totzke <patricktotzke@googlemail.com> wrote:
> That is surprising! I only fill the screen by iterating over an initial
> part of the iterator returned by Query.search_threads()
> I do a second query to count the messages by Query.count_messages(),
> but I'd guess that this translates to some sort of "SELECT COUNT"
> and should also be fast. Maybe there's some copying going on 
> at lower levels?

The "count" operation should be something very fast, yes.

It might be worth some investigation to see if there's actually a
problem here or not.

> >   * The '/' key didn't seem to do anything for me, so I wasn't able to
> >     actually do any custom searches.
> This is because it really is "\" :P that was a typo in the README.

Ah. Thanks. That definitely helps.

> Thanks, that's helpful. I guess it would make sense to place this under
> notmuch/contrib at a later point if it gets usable.

Sure. I'll be glad to do that. Just let me know when you want it.

> Ah I have question regarding "toplevel" messages in threads:
> How can it be that a mail that is not the one that started a thread
> is contained in thread.get_toplevel_messages() ?
> The only thing I can think of is that a user somehow forced two threads
> to become one. Take this very thread for example. Why do I get
> Mueen Nawaz's reply as a toplevel message? does this mean
> that messages header has incorrect Reply-to headers set?

Hmmm... I do seem to be seeing that behavior.

The message from Mueen Nawaz (id:"87y620subn.fsf@fester.com") does not
have any In-Reply-To header, but it does contain the following:

	References: <1305888097-sup-2343@optimusprime>

which is the correct message ID for the original top-level message in
the thread.

So it looks like there's a bug here in notmuch not correctly stitching
this message to its parent in this case. It should be an easy test case
to add to the suite (and hopefully an easy bug to fix as well).

-Carl