bug#35513: (setq gnus-thread-sort-functions '(gnus-thread-sort-by-number)) seems not to work always.

bug#35513: (setq gnus-thread-sort-functions '(gnus-thread-sort-by-number)) seems not to work always.

[Uwe Brauer]

I have set

(setq gnus-thread-sort-functions '(gnus-thread-sort-by-number)) 
but also 
(setq gnus-thread-ignore-subject nil)


Now look at the following ordering when threading is on.



 89532 [  Uwe Braue] Uwe Brauer  [First message sent       ] Tue, 30 Apr 2019 23:27:28 +0200 4.6k 1   
     89534 [  Uwe Braue] Uwe Brauer  [                         ] Tue, 30 Apr 2019 23:27:59 +0200 8.1k 3   
         89536 [  Uwe Braue] Uwe Brauer  [                         ] Tue, 30 Apr 2019 23:28:33 +0200 16k ?   
 89540 [  Uwe Braue] Uwe Brauer  [[New subject] (was: First] Tue, 30 Apr 2019 23:32:05 +0200 12k ?   
 89538 [  Uwe Braue] Uwe Brauer  [I sent a new message whic] Tue, 30 Apr 2019 23:29:54 +0200 7.8k 1   
 89542 [  Uwe Braue] Uwe Brauer  [[New message references k] Tue, 30 Apr 2019 23:32:43 +0200 12k ?   

You will see that  89540 is ordered *before*  89538.

How did that happen? Here is a step by step instruction.
(setq gnus-thread-ignore-subject nil)

Sent some message to say your other email address and reply via followup
that gives 
 89532 [  Uwe Braue] Uwe Brauer  [First message sent       ] Tue, 30 Apr 2019 23:27:28 +0200 4.6k 1   
     89534 [  Uwe Braue] Uwe Brauer  [                         ] Tue, 30 Apr 2019 23:27:59 +0200 8.1k 3   
         89536 [  Uwe Braue] Uwe Brauer  [                         ] Tue, 30 Apr 2019 23:28:33 +0200 16k ?   

Then I sent a new message which  does not belong to the thread, that is 
 89538 [  Uwe Braue] Uwe Brauer  [I sent a new message whic] Tue, 30 Apr 2019 23:29:54 +0200 7.8k 1   

Now I reply to  89536, change the subject but leave the reference
intact, that results in   89540, placed *before* 89538, which is not
correct. 

I reply (followup again to message 89536, change the subject and remove
the reference that indeed message 89542 is ordered correctly.

I think the current behavior is not intuitive and should be changed:
Messages should be always ordered (in that setting I described above) by
their number independent whether it has it source in a thread.

Regards

Uwe Brauer 

Gnus v5.13
GNU Emacs 27.0.50 (build 1, x86_64-pc-linux-gnu, X toolkit, Xaw3d scroll bars)
 of 2018-04-26
200 news.gmane.org InterNetNews NNRP server INN 2.6.1 ready (posting ok)
100 Legal commands
  ARTICLE [message-ID|number]
  AUTHINFO USER name|PASS password|SASL mechanism [initial-response]|GENERIC program [argument ...]
  BODY [message-ID|number]
  CAPABILITIES [keyword]
  COMPRESS DEFLATE
  DATE
  GROUP newsgroup
  HDR header [message-ID|range]
  HEAD [message-ID|number]
  HELP
  IHAVE message-ID
  LAST
  LIST [ACTIVE [wildmat]|ACTIVE.TIMES [wildmat]|COUNTS [wildmat]|DISTRIB.PATS|DISTRIBUTIONS|HEADERS [MSGID|RANGE]|MODERATORS|MOTD|NEWSGROUPS [wildmat]|OVERVIEW.FMT|SUBSCRIPTIONS [wildmat]]
  LISTGROUP [newsgroup [range]]
  MODE READER
  NEWGROUPS [yy]yymmdd hhmmss [GMT]
  NEWNEWS wildmat [yy]yymmdd hhmmss [GMT]
  NEXT
  OVER [range]
  POST
  QUIT
  STARTTLS
  STAT [message-ID|number]
  XGTITLE [wildmat]
  XHDR header [message-ID|range]
  XOVER [range]
  XPAT header message-ID|range pattern [pattern ...]
Report problems to <usenet@blaine.gmane.org>.
.
382 Begin TLS negotiation now
100 Legal commands
  ARTICLE [message-ID|number]
  AUTHINFO USER name|PASS password|SASL mechanism [initial-response]|GENERIC program [argument ...]
  BODY [message-ID|number]
  CAPABILITIES [keyword]
  COMPRESS DEFLATE
  DATE
  GROUP newsgroup
  HDR header [message-ID|range]
  HEAD [message-ID|number]
  HELP
  IHAVE message-ID
  LAST
  LIST [ACTIVE [wildmat]|ACTIVE.TIMES [wildmat]|COUNTS [wildmat]|DISTRIB.PATS|DISTRIBUTIONS|HEADERS [MSGID|RANGE]|MODERATORS|MOTD|NEWSGROUPS [wildmat]|OVERVIEW.FMT|SUBSCRIPTIONS [wildmat]]
  LISTGROUP [newsgroup [range]]
  MODE READER
  NEWGROUPS [yy]yymmdd hhmmss [GMT]
  NEWNEWS wildmat [yy]yymmdd hhmmss [GMT]
  NEXT
  OVER [range]
  POST
  QUIT
  STARTTLS
  STAT [message-ID|number]
  XGTITLE [wildmat]
  XHDR header [message-ID|range]
  XOVER [range]
  XPAT header message-ID|range pattern [pattern ...]
Report problems to <usenet@blaine.gmane.org>.
.

bug#35513: (setq gnus-thread-sort-functions '(gnus-thread-sort-by-number)) seems not to work always.

[Lars Ingebrigtsen]

Uwe Brauer <oub.oub.oub@gmail.com> writes:

> (setq gnus-thread-ignore-subject nil)

[...]

> Now I reply to  89536, change the subject but leave the reference
> intact, that results in   89540, placed *before* 89538, which is not
> correct. 

Yes -- the sorting is done before splitting threads up based on the
gnus-thread-ignore-subject, which seems like a bug.

Fixing this rather obscure problem would require traversing the thread
structure once more, which I'm not sure is worth it...

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

bug#35513: (setq gnus-thread-sort-functions '(gnus-thread-sort-by-number)) seems not to work always.

[Lars Ingebrigtsen]

Lars Ingebrigtsen <larsi@gnus.org> writes:

> Yes -- the sorting is done before splitting threads up based on the
> gnus-thread-ignore-subject, which seems like a bug.
>
> Fixing this rather obscure problem would require traversing the thread
> structure once more, which I'm not sure is worth it...

After pondering this, I've come to the conclusion that it's best just to
document this quirk instead of threading, then sorting, then splitting,
and then re-threading and re-sorting, and I'm closing this as a "wontfix".

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

bug#35513: (setq gnus-thread-sort-functions '(gnus-thread-sort-by-number)) seems not to work always.

[Uwe Brauer]

>>> "LI" == Lars Ingebrigtsen <larsi@gnus.org> writes:

   > Lars Ingebrigtsen <larsi@gnus.org> writes:
   >> Yes -- the sorting is done before splitting threads up based on the
   >> gnus-thread-ignore-subject, which seems like a bug.
   >> 
   >> Fixing this rather obscure problem would require traversing the thread
   >> structure once more, which I'm not sure is worth it...

   > After pondering this, I've come to the conclusion that it's best just to
   > document this quirk instead of threading, then sorting, then splitting,
   > and then re-threading and re-sorting, and I'm closing this as a "wontfix".

So you don't find it annoying and to difficult to implement and maybe to debug?

bug#35513: (setq gnus-thread-sort-functions '(gnus-thread-sort-by-number)) seems not to work always.

[Lars Ingebrigtsen]

Uwe Brauer <oub.oub.oub@gmail.com> writes:

> So you don't find it annoying and to difficult to implement and maybe
> to debug?

I think breaking threads on subject change is a misfeature, so enhancing
that misfeature doesn't seem appropriate.

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

bug#35513: (setq gnus-thread-sort-functions '(gnus-thread-sort-by-number)) seems not to work always.

[Uwe Brauer]

>>> "LI" == Lars Ingebrigtsen <larsi@gnus.org> writes:

   > Uwe Brauer <oub.oub.oub@gmail.com> writes:
   >> So you don't find it annoying and to difficult to implement and maybe
   >> to debug?

   > I think breaking threads on subject change is a misfeature, so enhancing
   > that misfeature doesn't seem appropriate.

So you are saying that if I change the subject line in a tread, I should
not break the thread?

I came to this feature by a recommendation of John Wiley.

If you change the subject, change the thread, for me that looks
logically, you say, no?

bug#35513: (setq gnus-thread-sort-functions '(gnus-thread-sort-by-number)) seems not to work always.

[Eric Abrahamsen]

Uwe Brauer <oub.oub.oub@gmail.com> writes:

>>>> "LI" == Lars Ingebrigtsen <larsi@gnus.org> writes:
>
>    > Uwe Brauer <oub.oub.oub@gmail.com> writes:
>    >> So you don't find it annoying and to difficult to implement and maybe
>    >> to debug?
>
>    > I think breaking threads on subject change is a misfeature, so enhancing
>    > that misfeature doesn't seem appropriate.
>
> So you are saying that if I change the subject line in a tread, I should
> not break the thread?
>
> I came to this feature by a recommendation of John Wiley.
>
> If you change the subject, change the thread, for me that looks
> logically, you say, no?

To me, no. I've always felt that threads should be built by reference,
not by subject. To me, reference headers feel like a "real" connection,
vs subject headers, which only happen to coincide.

Obviously this is totally subjective, and I only chime in to say that
other people (me) have a different "logical" interpretation of the
situation. But it's one of those areas of Gnus that everyone will have
different (strongly-held) opinions about.