"entire-thread" does not always show entire thread.

[larsks]

If I use the entire-thread command on a message, mutt-kz will sometimes report "no more messages in the thread" even when that is obviously not the case. For example, I have a vfolder defined like this:

        "Other" "notmuch://?query=tag:unread AND NOT tag:work AND tag:list &limit=500"

The first message in a thread is excluded by the tag:unread restriction. With the second message in the thread selected, entire-thread reports "No more messages in the thread." If I look up the In-Reply-To header of the message and explicitly search for that using an id: search, then of course it finds the correct message.

I have implemented my own version of entire-thread via a script:

#!/usr/bin/python

import sys
from email.parser import Parser
from email.utils import parseaddr

parser = Parser()
msg = parser.parse(sys.stdin)
msgid = msg['message-id'][1:-1]

print 'push "<vfolder-from-query>id:%s &type=threads<return>"' % (msgid)

Which I run like this:

macro index,pager \\r "<pipe-message>~/bin/query-msgid-thread > ~/tmp/vfolderquery<enter><enter-command>source ~/tmp/vfolderquery<enter>"

This works, and delivers the entire thread to me, but it's less convenient than the built-in entire-thread command.

[karelzak]

On Thu, Dec 19, 2013 at 06:25:53AM -0800, Lars Kellogg-Stedman wrote:

I have implemented my own version of entire-thread via a script:

#!/usr/bin/python

import sys
from email.parser import Parser
from email.utils import parseaddr

parser = Parser()
msg = parser.parse(sys.stdin)
msgid = msg['message-id'][1:-1]

print 'push "<vfolder-from-query>id:%s &type=threads<return>"' % (msgid)

Hmm... the command is based on thread-id generated by notmuch (in simple query like "thread:%").

For example "notmuch search id:$message-id" shows the thread id, so you can try to manually search for the thread by (<Esc>X):

<vfolder-from-query>thread:%s &type=threads

Not sure, maybe there is no thread id for the missing message.

You can compile mutt with --enable-debug and then try

./mutt -d 2

and in ~/.muttdebug0 will be debug output, maybe it will be possible to found the missing message Id in the debug log or so (maybe de-duplication does not work...).

Karel

Karel Zak [email protected] http://karelzak.blogspot.com

[larsks]

If that is the case, why does a search for id:themessageid &type=threads return the entire thread? Wouldn't this suffer from the same problem? Or does this explicitly track reference headers (in-reply-to, etc) rather than using the thread id?

[karelzak]

All this is handled by notmuch, mutt does not tracks the references -- it just asks for "thread:theThreadId" query and reads all messages and replies. Try on command line:

notmuch search thread:theThreadId

and compare the result with command output in mutt.

Note that also uses nm_exclude_tags= to exclude messages now (committed a few minutes ago).

[masoncl]

It's because read_threads_query checks the data limit (500 in your case), and adding more messages from expanding the thread would put us over the limit.