Re: 'notmuch search thread:<>' lists multiple threads

2018-04-21 Thread David Bremner
"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


Re: Bug? notmuch-emacs: "All tags" in notmuch-hello does not show all tags

2018-04-21 Thread Gregor Zattler
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: [PATCH 6/6] lib: choose oldest message when breaking reference loops

2018-04-21 Thread Tomi Ollila
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 **) ))
> @@ -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 **) ))
> + _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

2018-04-21 Thread Tomi Ollila
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