Hi OK I have now actually tested it, and I have read the patch more carefully, but I am afraid I still have concerns. The key problem is the patch assumes that the display of a thread in a search buffer depends only on the thread. And this is not true as the number of matching messages is displayed eg [10/19], and the author list is split into matching authors | unmatching authors. However, when the tags in a thread are changed the patch makes all search buffers containing that thread update to look the same. Indeed, if you change a tag on a single message I think the count will always update to be [1/??] as there is only one message matching the tag-change query. I think you could get round this by modifying your code only slightly -- rather than calling notmuch-search-update-result in notmuch-search-update-results, *just* update the tags, using something like notmuch-search-set-tags. (I have just tried this and it seems to work.) This is not perfect, as this will show tags of newly arrived messages in the thread, but that might well be acceptable. And this still keeps it to one call to the database, which avoids your (completely correct) performance concerns. > It may be possible to optimize this down to one batch search query per > notmuch-search buffer - however, this results in a large search query. > Not only would one take a while to execute, but the resulting query can > become too large to be passed as a command-line parameter, and "notmuch > search" does not seem to have a --batch switch to read queries from > standard input. This points to my next concern -- this is already a problem in the current patch. If you go into a moderately large search buffer, and do something like * +foo (to tag all the messages with foo), the tag step works because is uses the --batch switch to tag, but your search query doesn't. The options here are to: add --batch to search handling, or just decide not to do display the tag updates for large queries. Incidentally there also seems to a bug in the current that the first thread in a search buffer doesn't seem to get updated. I think you are using too low level functions -- things like notmuch-search-foreach-result might do exactly what you need. Finally, in the longer term, do you wanting to do this for tree and show buffers too? [An alternative approach, which I don't think I like but I mention in case others do -- we could only propagate tag changes to parent buffers. So updating a tag in a show buffer only updates the single search buffer that called it. This might avoid the large query problem as show buffers probably don't have large queries.] Best wishes Mark _______________________________________________ notmuch mailing list notmuch@notmuchmail.org https://notmuchmail.org/mailman/listinfo/notmuch