Re: Bug? notmuch-emacs: "All tags" in notmuch-hello does not show all tags
On Fri, Apr 20 2018, Gregor Zattler wrote: > Dear notmuch-emacs developers, > > I use a certain tag which until now is only used with regards to > one single message which is also tagged "spam". This certain tag > is among the output of notmuch search --output=tags '*' > > The part of notmuch-hello which is supposed to show "All tags" > does not show this certain tag. But it shows the certain tag with > count = 1 if I remove the tag "spam" from this message. The same > happens if this message is tagged "deleted" instead of "spam". > > > My ~/.notmuch-config contains: > > [search] > exclude_tags=deleted;spam; > > > The relevant section of my customzation.el contains: > > '(notmuch-hello-sections >'(notmuch-hello-insert-search notmuch-hello-insert-saved-searches > notmuch-hello-insert-recent-searches > (notmuch-hello-insert-tags-section "All > tags" :initially-hidden t nil nil))) > > > I can show the message in question with a search for > (is:spam OR NOT is:spam OR is:deleted OR NOT is:deleted) AND is:certaintag > notmuch-emacs then shows the single message and its tags. Among > those is the certain tag. > > > I expected the certain tag to be shown in the notmuch-hello > section "All tags" and consider it a bug that this is not the case. > > My guess is that somewhere in the code notmuch count is called > without --exclude=false. Hmm. Notmuch emacs client runs `notmuch search --output=tags '*'` and then `notmuch count --batch` for those. If that 'certain' tag was in output of notmuch search --output=tags '*' then I don't see a reason it not showing up (unless it somehow were included in notmuch-hello-hide-tags, but I cannot see how it could be there). I personally don't have any tags excluded and nothing related to *hello* in my ~/.emacs.d/custom.el -- and now that I experimented with [search] exclude_tags I just could not get it to work in any related way (the tag I try to exclude is seen in search --output=tags '*' and in notmuch count --batch outputs... $ notmuch config get search.exclude_tags tbd $ $ notmuch count --batch tag:tbd 1 $ $ notmuch search --output=tags '*' | grep tbd tbd Finally, I tried adding another tag to the one message with this 'tbd' -- and that another tag is shown in "All tags:" output. That doesn't mean there could not be a bug there, just that I cannot reproduce it... Tomi > > > Ciao; Gregor > -- > -... --- .-. . -.. ..--.. ...-.- ___ notmuch mailing list notmuch@notmuchmail.org https://notmuchmail.org/mailman/listinfo/notmuch
Re: [PATCH 6/6] lib: choose oldest message when breaking reference loops
On Fri, Apr 20 2018, David Bremner wrote: > This preserves a sensible thread order > --- > lib/thread.cc| 33 - > test/T050-new.sh | 1 - > 2 files changed, 24 insertions(+), 10 deletions(-) > > diff --git a/lib/thread.cc b/lib/thread.cc > index dbac002f..a6dc4e5a 100644 > --- a/lib/thread.cc > +++ b/lib/thread.cc > @@ -390,20 +390,18 @@ _thread_add_matched_message (notmuch_thread_t *thread, > static void > _resolve_thread_relationships (notmuch_thread_t *thread) > { > -notmuch_message_node_t *node; > +notmuch_message_node_t *node, *first_node; > notmuch_message_t *message, *parent; > const char *in_reply_to; > > -for (node = thread->message_list->head; node; node = node->next) { > +first_node = thread->message_list->head; > +if (!first_node) Our style *dictates* space after '!'. > + return; > + > +for (node = first_node->next; node; node = node->next) { > message = node->message; > in_reply_to = _notmuch_message_get_in_reply_to (message); > - /* > - * if we reach the end of the list without finding a top-level > - * message, that means the thread is a cycle (or set of > - * cycles) and any message can be considered top-level > - */ > - if ((thread->toplevel_list->head || node->next) && > - in_reply_to && strlen (in_reply_to) && > + if (in_reply_to && strlen (in_reply_to) && > g_hash_table_lookup_extended (thread->message_hash, > in_reply_to, NULL, > (void **) &parent)) > @@ -412,6 +410,23 @@ _resolve_thread_relationships (notmuch_thread_t *thread) > _notmuch_message_list_add_message (thread->toplevel_list, message); > } > > +/* > + * if we reach the end of the list without finding a top-level > + * message, that means the thread is a cycle (or set of cycles) > + * and any message can be considered top-level. Choose the oldest > + * message, which happens to be first in our list. > + */ > +message=first_node->message; > +in_reply_to = _notmuch_message_get_in_reply_to (message); > +if (thread->toplevel_list->head && > + in_reply_to && strlen (in_reply_to) && Otherwise the series _looks_ good do me. The thing that disturbs me are these `strlen (in_reply_to)` contents. Perhaps SomeOne(TM) changes these to e.g. in_reply_to[0] in the future... Tomi > + g_hash_table_lookup_extended (thread->message_hash, > + in_reply_to, NULL, > + (void **) &parent)) > + _notmuch_message_add_reply (parent, message); > +else > + _notmuch_message_list_add_message (thread->toplevel_list, message); > + > /* XXX: After scanning through the entire list looking for parents > * via "In-Reply-To", we should do a second pass that looks at the > * list of messages IDs in the "References" header instead. (And > diff --git a/test/T050-new.sh b/test/T050-new.sh > index 320a7646..9025fa7a 100755 > --- a/test/T050-new.sh > +++ b/test/T050-new.sh > @@ -359,7 +359,6 @@ test_begin_subtest "reference loop does not crash" > test_expect_code 0 "notmuch show --format=json id:mid-loop...@example.org > id:mid-loop...@example.org > OUTPUT" > > test_begin_subtest "reference loop ordered by date" > -test_subtest_known_broken > threadid=$(notmuch search --output=threads id:mid-loop...@example.org) > notmuch show --format=mbox $threadid | grep '^Date' > OUTPUT > cat < EXPECTED > -- > 2.17.0 > > ___ > notmuch mailing list > notmuch@notmuchmail.org > https://notmuchmail.org/mailman/listinfo/notmuch ___ notmuch mailing list notmuch@notmuchmail.org https://notmuchmail.org/mailman/listinfo/notmuch
Re: Bug? notmuch-emacs: "All tags" in notmuch-hello does not show all tags
Hi Tomi, notmuch-emacs developers, * Tomi Ollila [2018-04-21; 20:38]: [...] > That doesn't mean there could not be a bug there, just > that I cannot reproduce it... Thanks for your investigation. I now prepared a minimal example, please extract the archive in /tmp. It contains a quite minmalistic .notmuch-config, a Maildir with one email and a test script which runs notmuch new, notmuch tag, starts emacs with no configuration and hopefully shows notmuch-hello.[1] Please klick on "show", you'll see only one tag: "spam", klick on "spam" you'll see this one email shown with its four (!) tags: "inbox", "new" and "certaintag" are not shown in "All tags". At least this is what I see with emacs25 and emacs27 and current notmuch. Do you see the same? Thanks for investing time in this issue. Regards, gregor [1] The script tries to guess your notmuch/emacs source path as load-path for emacs. If this fails please edit the emacs invocation according to your local setup minimal-example.tar Description: Unix tar archive ___ notmuch mailing list notmuch@notmuchmail.org https://notmuchmail.org/mailman/listinfo/notmuch
Re: 'notmuch search thread:<>' lists multiple threads
"Naveen N. Rao" writes: > In my case, I seem to be having the In-Reply-To headers. I end up with > two files per message: one from my inbox and one from the gmane archive > that I pull in. All the messages from the gmane archive seem to have a > re-written 'In-Reply-To' header, but 'Message-Id' and 'References' are > the same. That sounds like essentially the same issue, due to the fact that notmuch prefers In-Reply-To when choosing a parent for a message. Currently the database is correct (or at least one not-crazy definition of correct): all of the reference and in-reply-to terms are attached to the message document in the database. On the other hand, the in memory data structures currently assume that In-reply-to is a unique value (with ties broken at indexing time). It might be that the solution is to read a list of in-reply-to values and use all of them in threading. At a quick glance, that looks doable; I'm just not sure about unintended consequences. d ___ notmuch mailing list notmuch@notmuchmail.org https://notmuchmail.org/mailman/listinfo/notmuch