[PATCH] Automatically exclude tags in notmuch-show
On Sun, 22 Jan 2012 20:52:22 -0500, Austin Clements wrote: > Quoth Mark Walters on Jan 23 at 1:13 am: > > On Sun, 22 Jan 2012 13:16:09 -0500, Austin Clements > > wrote: > > > Quoth myself on Jan 20 at 12:18 pm: > > > > 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: > > > > > 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. > > > > > > Here's a slightly crazier idea that's more library-invasive than the > > > original approach, but probably better in the long run. > > > > > > Have notmuch_query_search_* return everything and make exclusion a > > > message flag like NOTMUCH_MESSAGE_FLAG_MATCH. Tweak the definition of > > > "matched" to mean "matched and not excluded" (specifically, a message > > > would have the match flag or the excluded flag or neither, but not > > > both). Search would skip threads with zero matched messages and I > > > think show would Just Work. > > > > > > I can think of two ways to implement this. notmuch_query_search_* > > > could perform both the original query and the query with exclusions > > > and use the docid set from the second to compute the "excluded" > > > message flag. Alternatively, it could examine the tags of each > > > message directly to compute the flag. The latter is probably easier > > > to implement, but probably slower. > > > > > > Thoughts? > > > > I have now thought about this some more and think I understand your idea > > (and how it would work) rather better now. > > > > I would suggest one small change: the flags for the messages returned > > should be "independent": so a message can match the query or not, and it > > can be excluded or not, with all 4 combinations being possible. (The > > consumer of notmuch_query_search_* would extract the information it > > wanted.) > > I'd initially approached it this way, but went with redefining a > "matched" messages because it had much less impact on the API. For > example, with the redefined "match", > notmuch_thread_get_matched_messages still does the right thing for > search and things like the thread subject can still be based on > "matched" messages. If we orthongonalize these flags, then we at > least need to count matched non-excluded messages and provide an API > to access this (while I don't have a solid argument against such an > API it just seems weirdly specific to me). Ok I have an initial implementation of this which I will post as a reply to this thread: it does make the flags orthogonal but that would be easy to change. If we do want to keep match to mean match and not excluded then I would argue for a third flag so that the emacs frontend could see all 4 possibilities. Note that in your suggestion we still need to do something in notmuch_thread_get_matched_messages to set the subject etc in threads with no matching non-excluded messages. > My other concern is performance. In thread queries, marking > non-matched messages as excluded would require either an extra query > per thread or a single query to match all excluded messages (not > filtered by the primary query). The former is prohibitive, though the > latter
Re: [PATCH] Automatically exclude tags in notmuch-show
On Sun, 22 Jan 2012 20:52:22 -0500, Austin Clements amdra...@mit.edu wrote: Quoth Mark Walters on Jan 23 at 1:13 am: On Sun, 22 Jan 2012 13:16:09 -0500, Austin Clements amdra...@mit.edu wrote: Quoth myself on Jan 20 at 12:18 pm: 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. Here's a slightly crazier idea that's more library-invasive than the original approach, but probably better in the long run. Have notmuch_query_search_* return everything and make exclusion a message flag like NOTMUCH_MESSAGE_FLAG_MATCH. Tweak the definition of matched to mean matched and not excluded (specifically, a message would have the match flag or the excluded flag or neither, but not both). Search would skip threads with zero matched messages and I think show would Just Work. I can think of two ways to implement this. notmuch_query_search_* could perform both the original query and the query with exclusions and use the docid set from the second to compute the excluded message flag. Alternatively, it could examine the tags of each message directly to compute the flag. The latter is probably easier to implement, but probably slower. Thoughts? I have now thought about this some more and think I understand your idea (and how it would work) rather better now. I would suggest one small change: the flags for the messages returned should be independent: so a message can match the query or not, and it can be excluded or not, with all 4 combinations being possible. (The consumer of notmuch_query_search_* would extract the information it wanted.) I'd initially approached it this way, but went with redefining a matched messages because it had much less impact on the API. For example, with the redefined match, notmuch_thread_get_matched_messages still does the right thing for search and things like the thread subject can still be based on matched messages. If we orthongonalize these flags, then we at least need to count matched non-excluded messages and provide an API to access this (while I don't have a solid argument against such an API it just seems weirdly specific to me). Ok I have an initial implementation of this which I will post as a reply to this thread: it does make the flags orthogonal but that would be easy to change. If we do want to keep match to mean match and not excluded then I would argue for a third flag so that the emacs frontend could see all 4 possibilities. Note that in your suggestion we still need to do something in notmuch_thread_get_matched_messages to set the subject etc in threads with no matching non-excluded messages. My other concern is performance. In thread queries, marking non-matched messages as excluded would require either an extra query per thread or a single query to match all excluded messages (not filtered by the primary query). The former is prohibitive, though the latter might be acceptable (that might depend on how many things people mark as spam or deleted). If the cost is too high, this suggests that we shouldn't mark non-matched messages as excluded, but then we're back to effectively having three levels of matching: not
Re: [PATCH] Automatically exclude tags in notmuch-show
Quoth Mark Walters on Jan 24 at 1:05 am: On Sun, 22 Jan 2012 20:52:22 -0500, Austin Clements amdra...@mit.edu wrote: Quoth Mark Walters on Jan 23 at 1:13 am: On Sun, 22 Jan 2012 13:16:09 -0500, Austin Clements amdra...@mit.edu wrote: Quoth myself on Jan 20 at 12:18 pm: 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. Here's a slightly crazier idea that's more library-invasive than the original approach, but probably better in the long run. Have notmuch_query_search_* return everything and make exclusion a message flag like NOTMUCH_MESSAGE_FLAG_MATCH. Tweak the definition of matched to mean matched and not excluded (specifically, a message would have the match flag or the excluded flag or neither, but not both). Search would skip threads with zero matched messages and I think show would Just Work. I can think of two ways to implement this. notmuch_query_search_* could perform both the original query and the query with exclusions and use the docid set from the second to compute the excluded message flag. Alternatively, it could examine the tags of each message directly to compute the flag. The latter is probably easier to implement, but probably slower. Thoughts? I have now thought about this some more and think I understand your idea (and how it would work) rather better now. I would suggest one small change: the flags for the messages returned should be independent: so a message can match the query or not, and it can be excluded or not, with all 4 combinations being possible. (The consumer of notmuch_query_search_* would extract the information it wanted.) I'd initially approached it this way, but went with redefining a matched messages because it had much less impact on the API. For example, with the redefined match, notmuch_thread_get_matched_messages still does the right thing for search and things like the thread subject can still be based on matched messages. If we orthongonalize these flags, then we at least need to count matched non-excluded messages and provide an API to access this (while I don't have a solid argument against such an API it just seems weirdly specific to me). Ok I have an initial implementation of this which I will post as a reply to this thread: it does make the flags orthogonal but that would be easy to change. If we do want to keep match to mean match and not excluded then I would argue for a third flag so that the emacs frontend could see all 4 possibilities. Note that in your suggestion we still need to do something in notmuch_thread_get_matched_messages to set the subject etc in threads with no matching non-excluded messages. Cool. I was starting to hack together an implementation too, but I'll put that on hold. Since notmuch_thread_get_matched_messages just counts matched messages, it doesn't need anything special for threads with no matched messages, but you're right that something has to be done about the subjects of threads containing only excluded messages. Could you
[PATCH] Automatically exclude tags in notmuch-show
Quoth Mark Walters on Jan 24 at 1:05 am: > > On Sun, 22 Jan 2012 20:52:22 -0500, Austin Clements > wrote: > > Quoth Mark Walters on Jan 23 at 1:13 am: > > > On Sun, 22 Jan 2012 13:16:09 -0500, Austin Clements > > > wrote: > > > > Quoth myself on Jan 20 at 12:18 pm: > > > > > 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: > > > > > > 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. > > > > > > > > Here's a slightly crazier idea that's more library-invasive than the > > > > original approach, but probably better in the long run. > > > > > > > > Have notmuch_query_search_* return everything and make exclusion a > > > > message flag like NOTMUCH_MESSAGE_FLAG_MATCH. Tweak the definition of > > > > "matched" to mean "matched and not excluded" (specifically, a message > > > > would have the match flag or the excluded flag or neither, but not > > > > both). Search would skip threads with zero matched messages and I > > > > think show would Just Work. > > > > > > > > I can think of two ways to implement this. notmuch_query_search_* > > > > could perform both the original query and the query with exclusions > > > > and use the docid set from the second to compute the "excluded" > > > > message flag. Alternatively, it could examine the tags of each > > > > message directly to compute the flag. The latter is probably easier > > > > to implement, but probably slower. > > > > > > > > Thoughts? > > > > > > I have now thought about this some more and think I understand your idea > > > (and how it would work) rather better now. > > > > > > I would suggest one small change: the flags for the messages returned > > > should be "independent": so a message can match the query or not, and it > > > can be excluded or not, with all 4 combinations being possible. (The > > > consumer of notmuch_query_search_* would extract the information it > > > wanted.) > > > > I'd initially approached it this way, but went with redefining a > > "matched" messages because it had much less impact on the API. For > > example, with the redefined "match", > > notmuch_thread_get_matched_messages still does the right thing for > > search and things like the thread subject can still be based on > > "matched" messages. If we orthongonalize these flags, then we at > > least need to count matched non-excluded messages and provide an API > > to access this (while I don't have a solid argument against such an > > API it just seems weirdly specific to me). > > Ok I have an initial implementation of this which I will post as a reply > to this thread: it does make the flags orthogonal but that would be easy > to change. If we do want to keep match to mean match and not excluded > then I would argue for a third flag so that the emacs frontend could see > all 4 possibilities. Note that in your suggestion we still need to do > something in notmuch_thread_get_matched_messages to set the subject etc >
[PATCH] Automatically exclude tags in notmuch-show
On Sun, 22 Jan 2012 13:16:09 -0500, Austin Clements wrote: > Quoth myself on Jan 20 at 12:18 pm: > > 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: > > > 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. > > Here's a slightly crazier idea that's more library-invasive than the > original approach, but probably better in the long run. > > Have notmuch_query_search_* return everything and make exclusion a > message flag like NOTMUCH_MESSAGE_FLAG_MATCH. Tweak the definition of > "matched" to mean "matched and not excluded" (specifically, a message > would have the match flag or the excluded flag or neither, but not > both). Search would skip threads with zero matched messages and I > think show would Just Work. > > I can think of two ways to implement this. notmuch_query_search_* > could perform both the original query and the query with exclusions > and use the docid set from the second to compute the "excluded" > message flag. Alternatively, it could examine the tags of each > message directly to compute the flag. The latter is probably easier > to implement, but probably slower. > > Thoughts? I have now thought about this some more and think I understand your idea (and how it would work) rather better now. I would suggest one small change: the flags for the messages returned should be "independent": so a message can match the query or not, and it can be excluded or not, with all 4 combinations being possible. (The consumer of notmuch_query_search_* would extract the information it wanted.) I have thought about some implementation ideas but I think sorting is going to be the deciding factor: what order should notmuch_query_search_* return messages/threads? For notmuch_query_search_messages either it returns them all together with the excluded messages marked, or returns all included ones, and then all excluded one. For notmuch_query_search_threads it is less clear. Currently it returns threads in order of first matching message. It is not clear what matching means now: is matching and included, or just matching? If the former then we will be returning some threads with no matching and included messages so we need to decide where to put them in the order. If we sort in both cases just on matching then we have the same output/sort as notmuch pre-excluded flags, just the frontends notmuch-search/show can decide to omit some lines/results. Note that after omitting "excluded" lines the thread sort would be different from the current notmuch-with-excluded implementation. Whereas if we sort based on matching and included, we keep the current sort order with some stuff appended. As regards implementation I think notmuch_query_search_messages is the crucial place: once that returns one of its two orders the rest sort of takes care of itself. Best wishes Mark
[PATCH] Automatically exclude tags in notmuch-show
Quoth Mark Walters on Jan 23 at 1:13 am: > On Sun, 22 Jan 2012 13:16:09 -0500, Austin Clements > wrote: > > Quoth myself on Jan 20 at 12:18 pm: > > > 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: > > > > 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. > > > > Here's a slightly crazier idea that's more library-invasive than the > > original approach, but probably better in the long run. > > > > Have notmuch_query_search_* return everything and make exclusion a > > message flag like NOTMUCH_MESSAGE_FLAG_MATCH. Tweak the definition of > > "matched" to mean "matched and not excluded" (specifically, a message > > would have the match flag or the excluded flag or neither, but not > > both). Search would skip threads with zero matched messages and I > > think show would Just Work. > > > > I can think of two ways to implement this. notmuch_query_search_* > > could perform both the original query and the query with exclusions > > and use the docid set from the second to compute the "excluded" > > message flag. Alternatively, it could examine the tags of each > > message directly to compute the flag. The latter is probably easier > > to implement, but probably slower. > > > > Thoughts? > > I have now thought about this some more and think I understand your idea > (and how it would work) rather better now. > > I would suggest one small change: the flags for the messages returned > should be "independent": so a message can match the query or not, and it > can be excluded or not, with all 4 combinations being possible. (The > consumer of notmuch_query_search_* would extract the information it > wanted.) I'd initially approached it this way, but went with redefining a "matched" messages because it had much less impact on the API. For example, with the redefined "match", notmuch_thread_get_matched_messages still does the right thing for search and things like the thread subject can still be based on "matched" messages. If we orthongonalize these flags, then we at least need to count matched non-excluded messages and provide an API to access this (while I don't have a solid argument against such an API it just seems weirdly specific to me). My other concern is performance. In thread queries, marking non-matched messages as excluded would require either an extra query per thread or a single query to match all excluded messages (not filtered by the primary query). The former is prohibitive, though the latter might be acceptable (that might depend on how many things people mark as spam or deleted). If the cost is too high, this suggests that we shouldn't mark non-matched messages as excluded, but then we're back to effectively having three levels of matching: not matched, matched but not excluded, and matched but excluded. > I have thought about some implementation ideas but I think sorting is > going to be the deciding factor: what order should > notmuch_query_search_* return messages/threads? Yes. This is exactly what I've been puzzling over, too. > For notmuch_query_search_messages either it returns them all together > with the excluded messages marked, or returns all included ones, and > then all excluded one. I would prefer them
[PATCH] Automatically exclude tags in notmuch-show
On Sun, 22 Jan 2012 13:16:09 -0500, Austin Clements wrote: > Quoth myself on Jan 20 at 12:18 pm: > > 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: > > > 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. > > Here's a slightly crazier idea that's more library-invasive than the > original approach, but probably better in the long run. > > Have notmuch_query_search_* return everything and make exclusion a > message flag like NOTMUCH_MESSAGE_FLAG_MATCH. Tweak the definition of > "matched" to mean "matched and not excluded" (specifically, a message > would have the match flag or the excluded flag or neither, but not > both). Search would skip threads with zero matched messages and I > think show would Just Work. > > I can think of two ways to implement this. notmuch_query_search_* > could perform both the original query and the query with exclusions > and use the docid set from the second to compute the "excluded" > message flag. Alternatively, it could examine the tags of each > message directly to compute the flag. The latter is probably easier > to implement, but probably slower. I really like the idea of returning two flags. I think your first suggestion works better for sorting reasons: we want to return a thread which has a match-not-excluded message and also a match-excluded message to be sorted based on the match-not-excluded message. Hence in notmuch_query_search_threads we can create the list of docids to iterate over as the list generated by query with exclusions followed by the list without exclusions. This list contains lots of messages twice but that doesn't matter since we have to check whether we have already output the message in an earlier thread anyway. Incidentally, it might not take very much more code to allow notmuch_query_search_threads to take two arbitrary queries and return all threads which match the first case but mark as matched those that match the second: i.e. a step on the way towards "thread based and". Best wishes Mark
[PATCH] Automatically exclude tags in notmuch-show
Quoth myself on Jan 20 at 12:18 pm: > 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: > > 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. Here's a slightly crazier idea that's more library-invasive than the original approach, but probably better in the long run. Have notmuch_query_search_* return everything and make exclusion a message flag like NOTMUCH_MESSAGE_FLAG_MATCH. Tweak the definition of "matched" to mean "matched and not excluded" (specifically, a message would have the match flag or the excluded flag or neither, but not both). Search would skip threads with zero matched messages and I think show would Just Work. I can think of two ways to implement this. notmuch_query_search_* could perform both the original query and the query with exclusions and use the docid set from the second to compute the "excluded" message flag. Alternatively, it could examine the tags of each message directly to compute the flag. The latter is probably easier to implement, but probably slower. Thoughts?
[PATCH] Automatically exclude tags in notmuch-show
Quoth Mark Walters on Jan 22 at 12:38 am: > > On Fri, 20 Jan 2012 12:18:01 -0500, Austin Clements > wrote: > > > > 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. > > I have been thinking about this and one question is what should the sort > order be? If I understand it correctly notmuch sorts the threads > by the oldest/newest matching message, so the "correct" behaviour if no > message matches is unclear. Perhaps all threads with a matching > non-excluded message sorted by the matching-non-excluded message > followed by all threads that match only on excluded messages with sort > based on the matching excluded message? I don't think show sorts in any particular way. Or are you saying that search also needs to know the difference between excluded and non-excluded matched messages?
[PATCH] Automatically exclude tags in notmuch-show
On Fri, 20 Jan 2012 12:18:01 -0500, Austin Clements wrote: > > 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. I have been thinking about this and one question is what should the sort order be? If I understand it correctly notmuch sorts the threads by the oldest/newest matching message, so the "correct" behaviour if no message matches is unclear. Perhaps all threads with a matching non-excluded message sorted by the matching-non-excluded message followed by all threads that match only on excluded messages with sort based on the matching excluded message? Best wishes Mark
Re: [PATCH] Automatically exclude tags in notmuch-show
Quoth Mark Walters on Jan 22 at 12:38 am: On Fri, 20 Jan 2012 12:18:01 -0500, Austin Clements amdra...@mit.edu wrote: 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. I have been thinking about this and one question is what should the sort order be? If I understand it correctly notmuch sorts the threads by the oldest/newest matching message, so the correct behaviour if no message matches is unclear. Perhaps all threads with a matching non-excluded message sorted by the matching-non-excluded message followed by all threads that match only on excluded messages with sort based on the matching excluded message? I don't think show sorts in any particular way. Or are you saying that search also needs to know the difference between excluded and non-excluded matched messages? ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
Re: [PATCH] Automatically exclude tags in notmuch-show
Quoth myself on Jan 20 at 12:18 pm: 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. Here's a slightly crazier idea that's more library-invasive than the original approach, but probably better in the long run. Have notmuch_query_search_* return everything and make exclusion a message flag like NOTMUCH_MESSAGE_FLAG_MATCH. Tweak the definition of matched to mean matched and not excluded (specifically, a message would have the match flag or the excluded flag or neither, but not both). Search would skip threads with zero matched messages and I think show would Just Work. I can think of two ways to implement this. notmuch_query_search_* could perform both the original query and the query with exclusions and use the docid set from the second to compute the excluded message flag. Alternatively, it could examine the tags of each message directly to compute the flag. The latter is probably easier to implement, but probably slower. Thoughts? ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
Re: [PATCH] Automatically exclude tags in notmuch-show
On Sun, 22 Jan 2012 13:16:09 -0500, Austin Clements amdra...@mit.edu wrote: Quoth myself on Jan 20 at 12:18 pm: 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. Here's a slightly crazier idea that's more library-invasive than the original approach, but probably better in the long run. Have notmuch_query_search_* return everything and make exclusion a message flag like NOTMUCH_MESSAGE_FLAG_MATCH. Tweak the definition of matched to mean matched and not excluded (specifically, a message would have the match flag or the excluded flag or neither, but not both). Search would skip threads with zero matched messages and I think show would Just Work. I can think of two ways to implement this. notmuch_query_search_* could perform both the original query and the query with exclusions and use the docid set from the second to compute the excluded message flag. Alternatively, it could examine the tags of each message directly to compute the flag. The latter is probably easier to implement, but probably slower. I really like the idea of returning two flags. I think your first suggestion works better for sorting reasons: we want to return a thread which has a match-not-excluded message and also a match-excluded message to be sorted based on the match-not-excluded message. Hence in notmuch_query_search_threads we can create the list of docids to iterate over as the list generated by query with exclusions followed by the list without exclusions. This list contains lots of messages twice but that doesn't matter since we have to check whether we have already output the message in an earlier thread anyway. Incidentally, it might not take very much more code to allow notmuch_query_search_threads to take two arbitrary queries and return all threads which match the first case but mark as matched those that match the second: i.e. a step on the way towards thread based and. Best wishes Mark ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
Re: [PATCH] Automatically exclude tags in notmuch-show
On Sun, 22 Jan 2012 13:16:09 -0500, Austin Clements amdra...@mit.edu wrote: Quoth myself on Jan 20 at 12:18 pm: 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. Here's a slightly crazier idea that's more library-invasive than the original approach, but probably better in the long run. Have notmuch_query_search_* return everything and make exclusion a message flag like NOTMUCH_MESSAGE_FLAG_MATCH. Tweak the definition of matched to mean matched and not excluded (specifically, a message would have the match flag or the excluded flag or neither, but not both). Search would skip threads with zero matched messages and I think show would Just Work. I can think of two ways to implement this. notmuch_query_search_* could perform both the original query and the query with exclusions and use the docid set from the second to compute the excluded message flag. Alternatively, it could examine the tags of each message directly to compute the flag. The latter is probably easier to implement, but probably slower. Thoughts? I have now thought about this some more and think I understand your idea (and how it would work) rather better now. I would suggest one small change: the flags for the messages returned should be independent: so a message can match the query or not, and it can be excluded or not, with all 4 combinations being possible. (The consumer of notmuch_query_search_* would extract the information it wanted.) I have thought about some implementation ideas but I think sorting is going to be the deciding factor: what order should notmuch_query_search_* return messages/threads? For notmuch_query_search_messages either it returns them all together with the excluded messages marked, or returns all included ones, and then all excluded one. For notmuch_query_search_threads it is less clear. Currently it returns threads in order of first matching message. It is not clear what matching means now: is matching and included, or just matching? If the former then we will be returning some threads with no matching and included messages so we need to decide where to put them in the order. If we sort in both cases just on matching then we have the same output/sort as notmuch pre-excluded flags, just the frontends notmuch-search/show can decide to omit some lines/results. Note that after omitting excluded lines the thread sort would be different from the current notmuch-with-excluded implementation. Whereas if we sort based on matching and included, we keep the current sort order with some stuff appended. As regards implementation I think notmuch_query_search_messages is the crucial place: once that returns one of its two orders the rest sort of takes care of itself. Best wishes Mark ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
Re: [PATCH] Automatically exclude tags in notmuch-show
Quoth Mark Walters on Jan 23 at 1:13 am: On Sun, 22 Jan 2012 13:16:09 -0500, Austin Clements amdra...@mit.edu wrote: Quoth myself on Jan 20 at 12:18 pm: 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. Here's a slightly crazier idea that's more library-invasive than the original approach, but probably better in the long run. Have notmuch_query_search_* return everything and make exclusion a message flag like NOTMUCH_MESSAGE_FLAG_MATCH. Tweak the definition of matched to mean matched and not excluded (specifically, a message would have the match flag or the excluded flag or neither, but not both). Search would skip threads with zero matched messages and I think show would Just Work. I can think of two ways to implement this. notmuch_query_search_* could perform both the original query and the query with exclusions and use the docid set from the second to compute the excluded message flag. Alternatively, it could examine the tags of each message directly to compute the flag. The latter is probably easier to implement, but probably slower. Thoughts? I have now thought about this some more and think I understand your idea (and how it would work) rather better now. I would suggest one small change: the flags for the messages returned should be independent: so a message can match the query or not, and it can be excluded or not, with all 4 combinations being possible. (The consumer of notmuch_query_search_* would extract the information it wanted.) I'd initially approached it this way, but went with redefining a matched messages because it had much less impact on the API. For example, with the redefined match, notmuch_thread_get_matched_messages still does the right thing for search and things like the thread subject can still be based on matched messages. If we orthongonalize these flags, then we at least need to count matched non-excluded messages and provide an API to access this (while I don't have a solid argument against such an API it just seems weirdly specific to me). My other concern is performance. In thread queries, marking non-matched messages as excluded would require either an extra query per thread or a single query to match all excluded messages (not filtered by the primary query). The former is prohibitive, though the latter might be acceptable (that might depend on how many things people mark as spam or deleted). If the cost is too high, this suggests that we shouldn't mark non-matched messages as excluded, but then we're back to effectively having three levels of matching: not matched, matched but not excluded, and matched but excluded. I have thought about some implementation ideas but I think sorting is going to be the deciding factor: what order should notmuch_query_search_* return messages/threads? Yes. This is exactly what I've been puzzling over, too. For notmuch_query_search_messages either it returns them all together with the excluded messages marked, or returns all included ones, and then all excluded one. I would prefer them intermingled. I feel like returning one and then the other is just exposing implementation details. Plus, it's unclear if the order of the two groups should depend on the sort order, be
Re: [PATCH] Automatically exclude tags in notmuch-show
On Fri, 20 Jan 2012 12:18:01 -0500, Austin Clements amdra...@mit.edu wrote: 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. I have been thinking about this and one question is what should the sort order be? If I understand it correctly notmuch sorts the threads by the oldest/newest matching message, so the correct behaviour if no message matches is unclear. Perhaps all threads with a matching non-excluded message sorted by the matching-non-excluded message followed by all threads that match only on excluded messages with sort based on the matching excluded message? Best wishes Mark ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
[PATCH] Automatically exclude tags in notmuch-show
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: > 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.
[PATCH] Automatically exclude tags in notmuch-show
On Thu, 19 Jan 2012 17:59:10 -0500, Austin Clements wrote: > LGTM, but should definitely come with a test. > [...] > Also, this won't commute with Pieter's patch > (id:"1327000744-25463-2-git-send-email-pieter at praet.org"), so one or > the other will have to get updated. > No problem, I'll have to resubmit my entire series anyway, so go right ahead. > Quoth Mark Walters on Jan 19 at 10:03 pm: > > Add the use of auto_exclude_tags in notmuch-show.c. As with Austin's > > patch (commit 42a907992823030f070fc395a174f779998ca6f5) it just adds > > the excluded tags to the query so the excluded messages will still > > appear in the emacs interface, but as a single header line rather than > > as a matching message. > > --- > > notmuch-show.c |8 > > 1 files changed, 8 insertions(+), 0 deletions(-) > > > > diff --git a/notmuch-show.c b/notmuch-show.c > > index d14dac9..925dfd6 100644 > > --- a/notmuch-show.c > > +++ b/notmuch-show.c > > @@ -948,9 +948,12 @@ notmuch_show_command (void *ctx, unused (int argc), > > unused (char *argv[])) > > char *opt; > > const notmuch_show_format_t *format = _text; > > notmuch_show_params_t params; > > +const char **auto_exclude_tags; > > +size_t auto_exclude_tags_length; > > int mbox = 0; > > int format_specified = 0; > > int i; > > +unsigned int j; > > Hah. The original patch series updated 'count' to use the new > argument parsing solely so I could steal 'i' for the tag exclude code. > > > > > params.entire_thread = 0; > > params.raw = 0; > > @@ -1040,6 +1043,11 @@ notmuch_show_command (void *ctx, unused (int argc), > > unused (char *argv[])) > > return 1; > > } > > > > +auto_exclude_tags = notmuch_config_get_auto_exclude_tags > > +(config, _exclude_tags_length); > > +for (j = 0; j < auto_exclude_tags_length; j++) > > +notmuch_query_add_tag_exclude (query, auto_exclude_tags[j]); > > + > > /* if part was requested and format was not specified, use format=raw > > */ > > if (params.part >= 0 && !format_specified) > > format = _raw; > ___ > notmuch mailing list > notmuch at notmuchmail.org > http://notmuchmail.org/mailman/listinfo/notmuch Peace -- Pieter
[PATCH] Automatically exclude tags in notmuch-show
Ok Having said this is trivial I have found a problem. What should notmuch do if you do something like notmuch show 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? 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. Best wishes Mark
Re: [PATCH] Automatically exclude tags in notmuch-show
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. ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
[PATCH] Automatically exclude tags in notmuch-show
Add the use of auto_exclude_tags in notmuch-show.c. As with Austin's patch (commit 42a907992823030f070fc395a174f779998ca6f5) it just adds the excluded tags to the query so the excluded messages will still appear in the emacs interface, but as a single header line rather than as a matching message. --- notmuch-show.c |8 1 files changed, 8 insertions(+), 0 deletions(-) diff --git a/notmuch-show.c b/notmuch-show.c index d14dac9..925dfd6 100644 --- a/notmuch-show.c +++ b/notmuch-show.c @@ -948,9 +948,12 @@ notmuch_show_command (void *ctx, unused (int argc), unused (char *argv[])) char *opt; const notmuch_show_format_t *format = _text; notmuch_show_params_t params; +const char **auto_exclude_tags; +size_t auto_exclude_tags_length; int mbox = 0; int format_specified = 0; int i; +unsigned int j; params.entire_thread = 0; params.raw = 0; @@ -1040,6 +1043,11 @@ notmuch_show_command (void *ctx, unused (int argc), unused (char *argv[])) return 1; } +auto_exclude_tags = notmuch_config_get_auto_exclude_tags +(config, _exclude_tags_length); +for (j = 0; j < auto_exclude_tags_length; j++) +notmuch_query_add_tag_exclude (query, auto_exclude_tags[j]); + /* if part was requested and format was not specified, use format=raw */ if (params.part >= 0 && !format_specified) format = _raw; -- 1.7.2.3
[PATCH] Automatically exclude tags in notmuch-show
LGTM, but should definitely come with a test. Also, this won't commute with Pieter's patch (id:"1327000744-25463-2-git-send-email-pieter at praet.org"), so one or the other will have to get updated. Quoth Mark Walters on Jan 19 at 10:03 pm: > Add the use of auto_exclude_tags in notmuch-show.c. As with Austin's > patch (commit 42a907992823030f070fc395a174f779998ca6f5) it just adds > the excluded tags to the query so the excluded messages will still > appear in the emacs interface, but as a single header line rather than > as a matching message. > --- > notmuch-show.c |8 > 1 files changed, 8 insertions(+), 0 deletions(-) > > diff --git a/notmuch-show.c b/notmuch-show.c > index d14dac9..925dfd6 100644 > --- a/notmuch-show.c > +++ b/notmuch-show.c > @@ -948,9 +948,12 @@ notmuch_show_command (void *ctx, unused (int argc), > unused (char *argv[])) > char *opt; > const notmuch_show_format_t *format = _text; > notmuch_show_params_t params; > +const char **auto_exclude_tags; > +size_t auto_exclude_tags_length; > int mbox = 0; > int format_specified = 0; > int i; > +unsigned int j; Hah. The original patch series updated 'count' to use the new argument parsing solely so I could steal 'i' for the tag exclude code. > > params.entire_thread = 0; > params.raw = 0; > @@ -1040,6 +1043,11 @@ notmuch_show_command (void *ctx, unused (int argc), > unused (char *argv[])) > return 1; > } > > +auto_exclude_tags = notmuch_config_get_auto_exclude_tags > +(config, _exclude_tags_length); > +for (j = 0; j < auto_exclude_tags_length; j++) > +notmuch_query_add_tag_exclude (query, auto_exclude_tags[j]); > + > /* if part was requested and format was not specified, use format=raw */ > if (params.part >= 0 && !format_specified) > format = _raw;
[PATCH] Automatically exclude tags in notmuch-show
Add the use of auto_exclude_tags in notmuch-show.c. As with Austin's patch (commit 42a907992823030f070fc395a174f779998ca6f5) it just adds the excluded tags to the query so the excluded messages will still appear in the emacs interface, but as a single header line rather than as a matching message. --- notmuch-show.c |8 1 files changed, 8 insertions(+), 0 deletions(-) diff --git a/notmuch-show.c b/notmuch-show.c index d14dac9..925dfd6 100644 --- a/notmuch-show.c +++ b/notmuch-show.c @@ -948,9 +948,12 @@ notmuch_show_command (void *ctx, unused (int argc), unused (char *argv[])) char *opt; const notmuch_show_format_t *format = format_text; notmuch_show_params_t params; +const char **auto_exclude_tags; +size_t auto_exclude_tags_length; int mbox = 0; int format_specified = 0; int i; +unsigned int j; params.entire_thread = 0; params.raw = 0; @@ -1040,6 +1043,11 @@ notmuch_show_command (void *ctx, unused (int argc), unused (char *argv[])) return 1; } +auto_exclude_tags = notmuch_config_get_auto_exclude_tags +(config, auto_exclude_tags_length); +for (j = 0; j auto_exclude_tags_length; j++) +notmuch_query_add_tag_exclude (query, auto_exclude_tags[j]); + /* if part was requested and format was not specified, use format=raw */ if (params.part = 0 !format_specified) format = format_raw; -- 1.7.2.3 ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
Re: [PATCH] Automatically exclude tags in notmuch-show
LGTM, but should definitely come with a test. Also, this won't commute with Pieter's patch (id:1327000744-25463-2-git-send-email-pie...@praet.org), so one or the other will have to get updated. Quoth Mark Walters on Jan 19 at 10:03 pm: Add the use of auto_exclude_tags in notmuch-show.c. As with Austin's patch (commit 42a907992823030f070fc395a174f779998ca6f5) it just adds the excluded tags to the query so the excluded messages will still appear in the emacs interface, but as a single header line rather than as a matching message. --- notmuch-show.c |8 1 files changed, 8 insertions(+), 0 deletions(-) diff --git a/notmuch-show.c b/notmuch-show.c index d14dac9..925dfd6 100644 --- a/notmuch-show.c +++ b/notmuch-show.c @@ -948,9 +948,12 @@ notmuch_show_command (void *ctx, unused (int argc), unused (char *argv[])) char *opt; const notmuch_show_format_t *format = format_text; notmuch_show_params_t params; +const char **auto_exclude_tags; +size_t auto_exclude_tags_length; int mbox = 0; int format_specified = 0; int i; +unsigned int j; Hah. The original patch series updated 'count' to use the new argument parsing solely so I could steal 'i' for the tag exclude code. params.entire_thread = 0; params.raw = 0; @@ -1040,6 +1043,11 @@ notmuch_show_command (void *ctx, unused (int argc), unused (char *argv[])) return 1; } +auto_exclude_tags = notmuch_config_get_auto_exclude_tags +(config, auto_exclude_tags_length); +for (j = 0; j auto_exclude_tags_length; j++) +notmuch_query_add_tag_exclude (query, auto_exclude_tags[j]); + /* if part was requested and format was not specified, use format=raw */ if (params.part = 0 !format_specified) format = format_raw; ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
Re: [PATCH] Automatically exclude tags in notmuch-show
On Thu, 19 Jan 2012 17:59:10 -0500, Austin Clements amdra...@mit.edu wrote: LGTM, but should definitely come with a test. [...] Also, this won't commute with Pieter's patch (id:1327000744-25463-2-git-send-email-pie...@praet.org), so one or the other will have to get updated. No problem, I'll have to resubmit my entire series anyway, so go right ahead. Quoth Mark Walters on Jan 19 at 10:03 pm: Add the use of auto_exclude_tags in notmuch-show.c. As with Austin's patch (commit 42a907992823030f070fc395a174f779998ca6f5) it just adds the excluded tags to the query so the excluded messages will still appear in the emacs interface, but as a single header line rather than as a matching message. --- notmuch-show.c |8 1 files changed, 8 insertions(+), 0 deletions(-) diff --git a/notmuch-show.c b/notmuch-show.c index d14dac9..925dfd6 100644 --- a/notmuch-show.c +++ b/notmuch-show.c @@ -948,9 +948,12 @@ notmuch_show_command (void *ctx, unused (int argc), unused (char *argv[])) char *opt; const notmuch_show_format_t *format = format_text; notmuch_show_params_t params; +const char **auto_exclude_tags; +size_t auto_exclude_tags_length; int mbox = 0; int format_specified = 0; int i; +unsigned int j; Hah. The original patch series updated 'count' to use the new argument parsing solely so I could steal 'i' for the tag exclude code. params.entire_thread = 0; params.raw = 0; @@ -1040,6 +1043,11 @@ notmuch_show_command (void *ctx, unused (int argc), unused (char *argv[])) return 1; } +auto_exclude_tags = notmuch_config_get_auto_exclude_tags +(config, auto_exclude_tags_length); +for (j = 0; j auto_exclude_tags_length; j++) +notmuch_query_add_tag_exclude (query, auto_exclude_tags[j]); + /* if part was requested and format was not specified, use format=raw */ if (params.part = 0 !format_specified) format = format_raw; ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch Peace -- Pieter ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
Re: [PATCH] Automatically exclude tags in notmuch-show
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? 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. Best wishes Mark ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
