[PATCH] Automatically exclude tags in notmuch-show

[Austin Clements]

Quoth Mark Walters on Jan 20 at 12:10 am:
> 
> Ok Having said this is trivial I have found a problem. What should
> notmuch do if you do something like
> 
> notmuch show id:<some-id>
> and that message is marked with a deleted tag? To be consistent with the
> other cases (where a deleted message is in a matched thread) we might
> want to return the message with the not-matched flag set (eg in
> JSON). But my patch doesn't, as it never even sees the thread since it
> doesn't match.
> 
> Looking at notmuch-show.c I think we should not apply the exclude tags
> to do_show_single, but usually should apply it to do_show. One solution
> which is simple and is at least close to right would be to get do_show
> to return the number of threads found. If this is zero then retry the
> query without the excludes (possible setting the match_flag to zero on
> each message since we know it does not match)
> 
> This is not a completely correct solution as if you ask notmuch-show to
> show more than one thread it might  threads which only contain deleted
> messages.
> 
> I can't see other good possibilities without slowing down the normal
> path a lot (eg find all threads that match the original query and then
> apply the argument above).
> 
> Any thoughts?

Oh dear.

Well, here's one idea.  Instead of doing a single thread query in
show, do a thread query without the exclusions and then a message
query with the exclusions.  Output all of the messages from the first
query, but use the results of the second query to determine which
messages are "matched".  The same could be accomplished in the library
somewhat more efficiently, but it's not obvious to me what the API
would be.

> Incidentally, is there something strange at the end of notmuch-show.c: I
> can't see how we could ever reach the last half dozen lines.

Yes, I've wondered about that before, too.  I think none of those
technically matter since they're all cleaning up resources that the OS
is about to clean up for us.  It would be a problem if the database
was open in write mode because Xapian's write lock hangs around for a
split second after the process terminates if you don't close the
database yourself, but in read mode it doesn't take any locks.  Not
that this excuses the code.