Sparse threads in Gnus

Sparse threads in Gnus

[Toon Claes]

[-- Attachment #1: Type: text/plain, Size: 689 bytes --]

Hi,

Not sure if this is correct location to ask, but I'll give it a try.

I have "some system" (Gitlab.com in this case) that sends mails with
`In-Reply-To` and `References` headers. e.g.:

In-Reply-To: <issue_10837632@gitlab.com>
References: <issue_10837632@gitlab.com>
            <reply-REDACTED-HASH@gitlab.com>

I've been digging in the Gnus code, and it seems that Gnus bases
threading only on the last item in References and ignores all the other
Message IDs in the References header, and also ignores the In-Reply-To
header.

How can I make Gnus perform "Sparse threading" so it properly threads
the above under the mail with Message-ID: <issue_10837632@gitlab.com> ?


-- Toon



[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 832 bytes --]

Re: Sparse threads in Gnus

[Andreas Schwab]

On Mai 16 2018, Toon Claes <toon@iotcl.com> wrote:

> I have "some system" (Gitlab.com in this case) that sends mails with
> `In-Reply-To` and `References` headers. e.g.:
>
> In-Reply-To: <issue_10837632@gitlab.com>
> References: <issue_10837632@gitlab.com>
>             <reply-REDACTED-HASH@gitlab.com>

According to RFC 2822 the _last_ entry in the References: header is the
immediate parent (thus should be the same as the reference in the
In-Reply-To: header).

Andreas.

-- 
Andreas Schwab, SUSE Labs, schwab@suse.de
GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE  1748 E4D4 88E3 0EEA B9D7
"And now for something completely different."

Re: Sparse threads in Gnus

[Toon Claes]

[-- Attachment #1: Type: text/plain, Size: 337 bytes --]

Andreas Schwab <schwab@suse.de> writes:

> According to RFC 2822 the _last_ entry in the References: header is the
> immediate parent (thus should be the same as the reference in the
> In-Reply-To: header).

OK, thanks cool. But when I would remove a mail in the middle of a
thread, can I make Gnus still show it as one thread?

-- Toon

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 832 bytes --]

Re: Sparse threads in Gnus

[Lars Ingebrigtsen]

Toon Claes <toon@iotcl.com> writes:

> Andreas Schwab <schwab@suse.de> writes:
>
>> According to RFC 2822 the _last_ entry in the References: header is the
>> immediate parent (thus should be the same as the reference in the
>> In-Reply-To: header).
>
> OK, thanks cool. But when I would remove a mail in the middle of a
> thread, can I make Gnus still show it as one thread?

I'm not sure I understand the question -- if you set
`gnus-build-sparse-threads', does Gnus not do that?

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Re: Sparse threads in Gnus

[Toon Claes]

[-- Attachment #1: Type: text/plain, Size: 1308 bytes --]

Lars Ingebrigtsen <larsi@gnus.org> writes:

> I'm not sure I understand the question -- if you set
> `gnus-build-sparse-threads', does Gnus not do that?

Cool, I didn't know about this setting!

This helps! Although, is it possible to hide the sparse messages (with Q
mark)? So the tree would be similar, but the gaps wouldn't be visible. 

Because, when I run (gnus-summary-limit-exclude-marks "Q"), the tree structure
seems to be flattened again.

I've been taking a peek at the code and it doesn't seem easy to me to
achieve this, because the way the gnus-build-sparse-threads function
works, is to just create the missing messages, so all the other code can
just rely on "all messages being there".

That was I meant in my original question: There are multiple message ids
in the References header, but Gnus only uses the last message in that
list to build the threads. I'd like Gnus to build threads using the
"closest grandparent" algorithm.

E.g. a tree like this:

<Message-ID: A@example.com>
  <Message-ID: C@example.com; References: A@example.com, B@example.com>
    <Message-ID: D@example.com; References: A@example.com, B@example.com, C@example.com>
  <Message-ID: E@example.com; References: A@example.com, B@example.com, non-existing@example.com>
  



-- Toon

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 832 bytes --]

Re: Sparse threads in Gnus

[Toon Claes]

[-- Attachment #1: Type: text/plain, Size: 1308 bytes --]

Lars Ingebrigtsen <larsi@gnus.org> writes:

> I'm not sure I understand the question -- if you set
> `gnus-build-sparse-threads', does Gnus not do that?

Cool, I didn't know about this setting!

This helps! Although, is it possible to hide the sparse messages (with Q
mark)? So the tree would be similar, but the gaps wouldn't be visible. 

Because, when I run (gnus-summary-limit-exclude-marks "Q"), the tree structure
seems to be flattened again.

I've been taking a peek at the code and it doesn't seem easy to me to
achieve this, because the way the gnus-build-sparse-threads function
works, is to just create the missing messages, so all the other code can
just rely on "all messages being there".

That was I meant in my original question: There are multiple message ids
in the References header, but Gnus only uses the last message in that
list to build the threads. I'd like Gnus to build threads using the
"closest grandparent" algorithm.

E.g. a tree like this:

<Message-ID: A@example.com>
  <Message-ID: C@example.com; References: A@example.com, B@example.com>
    <Message-ID: D@example.com; References: A@example.com, B@example.com, C@example.com>
  <Message-ID: E@example.com; References: A@example.com, B@example.com, non-existing@example.com>
  



-- Toon

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 832 bytes --]