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.