wish list: thread-gathering sort options

wish list: thread-gathering sort options

[Ken Raeburn]

I'm trying to change the way my mail groups are sorted.  I've been
gathering threads by subject, and sorting by date.  What I'd like to
do instead is sort by "last date the thread way active".  Finding and
sorting on the latest date in a thread isn't hard, I wrote that code.
Problem is, the thread gathering assumes that when threads are
gathered, they should go in the position of the first thread, and the
sorting is applied before gathering threads.  In my case, the latest
thread is the last one, and that's the position where I want the
gathered threads to go.

I could probably get something more consistent to happen by putting
newest threads first, but I want the current (oldest-first) style of
listing both for sorting gathered threads and for the separate threads
gathered together.  I just want to use the latest date in the gathered
threads as the sort key.

Can I have some sort of option to control how gathered threads are
placed, or perhaps sort after gathering?

Ken

Re: wish list: thread-gathering sort options

[Kai Großjohann]

Ken Raeburn <raeburn@raeburn.org> writes:

> I'm trying to change the way my mail groups are sorted.  I've been
> gathering threads by subject, and sorting by date.  What I'd like to
> do instead is sort by "last date the thread way active".

I wonder if the following does the trick?

(when (fboundp 'gnus-thread-sort-by-most-recent-number)
  (setq gnus-thread-sort-functions '((not gnus-thread-sort-by-most-recent-number))))

Though it's not by date...

kai
-- 
Silence is foo!

Re: wish list: thread-gathering sort options

[Ken Raeburn]

Kai.Grossjohann@CS.Uni-Dortmund.DE (Kai Großjohann) writes:
> Ken Raeburn <raeburn@raeburn.org> writes:
>> I'm trying to change the way my mail groups are sorted.  I've been
>> gathering threads by subject, and sorting by date.  What I'd like to
>> do instead is sort by "last date the thread way active".

s/way/was/

> I wonder if the following does the trick?
>
> (when (fboundp 'gnus-thread-sort-by-most-recent-number)
>   (setq gnus-thread-sort-functions '((not gnus-thread-sort-by-most-recent-number))))
>
> Though it's not by date...

I overlooked that, I guess, and wrote the equivalent for date parsing
while working on this.  That gets the initial sorting more or less
right, but just the threads as pulled together based on message-ids;
when threads with similar subjects are then collected together, the
ordering in that phase doesn't come out the way I want it:

E.  43380 30-Apr[  15:Stainless Steel] Re: Are the latest Oort features better 
E.      43387 01-May<  31:Karl Eichwalder> 
E.      43388 01-May<  10:Per Abrahamsen > 
E.          43395 01-May[  13:Kai Großjohann ] 
E.          43412 01-May[  21:Daniel Pittman ] 
E.              43418 02-May[  12:Kai Großjohann ] 
E.                  43419 02-May[  18:Daniel Pittman ] 
E   43341 30-Apr[  12:Lars Bjønnes   ] Can topic parameters set group level?
E       43365 30-Apr[  14:Josh Huber     ] 
E.          43383 30-Apr[  22:Lars Bjønnes   ] 
E.              43386 30-Apr[  28:Josh Huber     ] 
 .  43406 01-May[  19:Oystein Viggen ] bug with imap in newest ognus snapshot
 .      43408 01-May[  10:Simon Josefsson] 
 .          43409 01-May[  11:Oystein Viggen ] 
 .  43400 01-May[  17:Bill White     ] fast email downloading?
 .      43417 02-May[  22:Kai Großjohann ] 

In this case, I want the "Oort features" thread placed based on the
highest number in all the gathered threads (43419), not the highest
number in the first thread (43380).

Ken

Re: wish list: thread-gathering sort options

[Kai Großjohann]

Ken Raeburn <raeburn@raeburn.org> writes:

> Kai.Grossjohann@CS.Uni-Dortmund.DE (Kai Grojohann) writes:
>> Ken Raeburn <raeburn@raeburn.org> writes:
>>> I'm trying to change the way my mail groups are sorted.  I've been
>>> gathering threads by subject, and sorting by date.  What I'd like to
>>> do instead is sort by "last date the thread way active".
>
> s/way/was/
>
>> I wonder if the following does the trick?
>>
>> (when (fboundp 'gnus-thread-sort-by-most-recent-number)
>>   (setq gnus-thread-sort-functions '((not gnus-thread-sort-by-most-recent-number))))
>>
>> Though it's not by date...
>
> I overlooked that, I guess, and wrote the equivalent for date parsing
> while working on this.

So, did you try gnus-thread-sort-by-most-recent-date instead of
gnus-thread-sort-by-most-recent-number?

kai
-- 
Silence is foo!

Re: wish list: thread-gathering sort options

[Ken Raeburn]

Kai.Grossjohann@CS.Uni-Dortmund.DE (Kai Großjohann) writes:
> So, did you try gnus-thread-sort-by-most-recent-date instead of
> gnus-thread-sort-by-most-recent-number?

Yes, I just tried it, and overall it's probably a little better than
most-recent-number, but it's still the post-gathering order I'm
dissatisfied with.

Re: wish list: thread-gathering sort options

[Kai Großjohann]

Ken Raeburn <raeburn@raeburn.org> writes:

> E.  43380 30-Apr[  15:Stainless Steel] Re: Are the latest Oort features better 
> E.      43387 01-May<  31:Karl Eichwalder> 
> E.      43388 01-May<  10:Per Abrahamsen > 
> E.          43395 01-May[  13:Kai Grojohann ] 
> E.          43412 01-May[  21:Daniel Pittman ] 
> E.              43418 02-May[  12:Kai Grojohann ] 
> E.                  43419 02-May[  18:Daniel Pittman ] 
> E   43341 30-Apr[  12:Lars Bjnnes   ] Can topic parameters set group level?
> E       43365 30-Apr[  14:Josh Huber     ] 
> E.          43383 30-Apr[  22:Lars Bjnnes   ] 
> E.              43386 30-Apr[  28:Josh Huber     ] 
>  .  43406 01-May[  19:Oystein Viggen ] bug with imap in newest ognus snapshot
>  .      43408 01-May[  10:Simon Josefsson] 
>  .          43409 01-May[  11:Oystein Viggen ] 
>  .  43400 01-May[  17:Bill White     ] fast email downloading?
>  .      43417 02-May[  22:Kai Grojohann ] 

This sorting order is really strange: it is neither sorted by the
root of the thread (43380, 43341, 43406, 43400 is not monotonic), nor
is it sorted by the maximum number in each thread (43419, 43386,
43409, 43417 is not monotonic, either).

Maybe this is sorted by scores?

kai
-- 
Silence is foo!

Re: wish list: thread-gathering sort options

[Ken Raeburn]

Kai.Grossjohann@CS.Uni-Dortmund.DE (Kai Großjohann) writes:
> Ken Raeburn <raeburn@raeburn.org> writes:
>> E.  43380 30-Apr[  15:Stainless Steel] Re: Are the latest Oort features better 
>> E.      43387 01-May<  31:Karl Eichwalder> 
>> E.      43388 01-May<  10:Per Abrahamsen > 
>> E.          43395 01-May[  13:Kai Grojohann ] 
>> E.          43412 01-May[  21:Daniel Pittman ] 
>> E.              43418 02-May[  12:Kai Grojohann ] 
>> E.                  43419 02-May[  18:Daniel Pittman ] 
>> E   43341 30-Apr[  12:Lars Bjnnes   ] Can topic parameters set group level?
>> E       43365 30-Apr[  14:Josh Huber     ] 
>> E.          43383 30-Apr[  22:Lars Bjnnes   ] 
>> E.              43386 30-Apr[  28:Josh Huber     ] 
>>  .  43406 01-May[  19:Oystein Viggen ] bug with imap in newest ognus snapshot
>>  .      43408 01-May[  10:Simon Josefsson] 
>>  .          43409 01-May[  11:Oystein Viggen ] 
>>  .  43400 01-May[  17:Bill White     ] fast email downloading?
>>  .      43417 02-May[  22:Kai Grojohann ] 
>
> This sorting order is really strange: it is neither sorted by the
> root of the thread (43380, 43341, 43406, 43400 is not monotonic), nor
> is it sorted by the maximum number in each thread (43419, 43386,
> 43409, 43417 is not monotonic, either).

As I said before, the individual threads are sorted numerically by
highest number:

43380 43386 43387 43409 43417 43419

and then the threads with related subjects are gathered together and
kept at the position of the *first* of the threads in each set:

(43380,43387,43419) 43386 43409 43417

I don't think there was any reference/reply relationship between
43380, 43387, and 43388.  So they were different threads when the
sorting pass happened.  (There may have been common ancestor articles
in this instance, but in real life I'm also losing on articles where
there is no "references:" header at all but the subjects match, and I
configured Gnus to gather threads by matching subjects.)


> Maybe this is sorted by scores?

Nope, I don't use scoring.

Ken

Re: wish list: thread-gathering sort options

[Kai Großjohann]

Ken Raeburn <raeburn@raeburn.org> writes:

Maybe there is a misunderstanding of how to parse this display.  I'm
going by indentation, and I can see four threads, indicated by blank
lines below.

> E.  43380 30-Apr[  15:Stainless Steel] Re: Are the latest Oort features better 
> E.      43387 01-May<  31:Karl Eichwalder> 
> E.      43388 01-May<  10:Per Abrahamsen > 
> E.          43395 01-May[  13:Kai Grojohann ] 
> E.          43412 01-May[  21:Daniel Pittman ] 
> E.              43418 02-May[  12:Kai Grojohann ] 
> E.                  43419 02-May[  18:Daniel Pittman ] 


> E   43341 30-Apr[  12:Lars Bjnnes   ] Can topic parameters set group level?
> E       43365 30-Apr[  14:Josh Huber     ] 
> E.          43383 30-Apr[  22:Lars Bjnnes   ] 
> E.              43386 30-Apr[  28:Josh Huber     ] 


>  .  43406 01-May[  19:Oystein Viggen ] bug with imap in newest ognus snapshot
>  .      43408 01-May[  10:Simon Josefsson] 
>  .          43409 01-May[  11:Oystein Viggen ] 


>  .  43400 01-May[  17:Bill White     ] fast email downloading?
>  .      43417 02-May[  22:Kai Grojohann ] 

Is this parsing correct?  (I turned off the <...> display in 1996 or
so, using only [...] and therefore I've now completely forgotten what
it means.  (Actually, I turned off the [...] some months ago, too.))

kai
-- 
Silence is foo!

Re: wish list: thread-gathering sort options

[Ken Raeburn]

Kai.Grossjohann@CS.Uni-Dortmund.DE (Kai Großjohann) writes:
> Maybe there is a misunderstanding of how to parse this display.  I'm
> going by indentation, and I can see four threads, indicated by blank
> lines below.
>
>> E.  43380 30-Apr[  15:Stainless Steel] Re: Are the latest Oort features better 
>> E.      43387 01-May<  31:Karl Eichwalder> 
>> E.      43388 01-May<  10:Per Abrahamsen > 
>> E.          43395 01-May[  13:Kai Grojohann ] 
>> E.          43412 01-May[  21:Daniel Pittman ] 
>> E.              43418 02-May[  12:Kai Grojohann ] 
>> E.                  43419 02-May[  18:Daniel Pittman ] 


> Is this parsing correct?  (I turned off the <...> display in 1996 or
> so, using only [...] and therefore I've now completely forgotten what
> it means.  (Actually, I turned off the [...] some months ago, too.))

The <...> means it's the start of a loose thread connected not by
references but by thread-gathering.  So, in some ways it's treated as
part of the same thread, but sorting isn't one of those ways.

C-h v says:

    gnus-summary-thread-gathering-function's value is 
    gnus-gather-threads-by-subject

    ...

Ken

Re: wish list: thread-gathering sort options

[Kai Großjohann]

Ken Raeburn <raeburn@raeburn.org> writes:

> The <...> means it's the start of a loose thread connected not by
> references but by thread-gathering.  So, in some ways it's treated as
> part of the same thread, but sorting isn't one of those ways.

Hm.  So, now I'm confused as to what should be done.  Sorry for the
line noise :-|

kai
-- 
Silence is foo!

Re: wish list: thread-gathering sort options

[Truxton Fulton]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset=utf-8, Size: 3852 bytes --]

Hi,

I've been looking at this problem, since I too want my threads to
be sorted so that the thread with the most recent message will
appear at the bottom of my summary buffer.  I'm using this :

(setq gnus-thread-sort-functions
      '((not gnus-thread-sort-by-most-recent-number)))

(setq gnus-summary-make-false-root 'adopt)        ; (the default)

The problem seems to be that despite the "adoption" method
for making a false root to gather orphaned threads, 
gnus-thread-highest-number only looks at the non-adopted
messages in the thread.

I found a work-around that does the trick for me.  The thread
gathering process gathers lower threads up to the higher thread.
If this could be reversed (since the thread sorting order is also
reversed), that would solve the problem.

This can be accomplished in gnus-sum.el:gnus-summary-prepare
like this :

+++ gnus-sum.el Sat Jul 13 15:27:48 2002
@@ -3470,9 +3470,11 @@
       (gnus-summary-prepare-threads
        (if gnus-show-threads
           (gnus-sort-gathered-threads
-           (funcall gnus-summary-thread-gathering-function
-                    (gnus-sort-threads
-                     (gnus-cut-threads (gnus-make-threads)))))
+           (reverse
+            (funcall gnus-summary-thread-gathering-function
+                     (reverse
+                      (gnus-sort-threads
+                       (gnus-cut-threads (gnus-make-threads)))))))
         ;; Unthreaded display.
         (gnus-sort-articles gnus-newsgroup-headers))))
     (setq gnus-newsgroup-data (nreverse gnus-newsgroup-data))

I'm sure there's a better way, since this will only do good things
for those of us with the most recent messages at the bottom of the
buffer.

-Truxton


Ken Raeburn <raeburn@raeburn.org> writes:

> Kai.Grossjohann@CS.Uni-Dortmund.DE (Kai Großjohann) writes:
>> Ken Raeburn <raeburn@raeburn.org> writes:
>>> I'm trying to change the way my mail groups are sorted.  I've been
>>> gathering threads by subject, and sorting by date.  What I'd like to
>>> do instead is sort by "last date the thread way active".
>
> s/way/was/
>
>> I wonder if the following does the trick?
>>
>> (when (fboundp 'gnus-thread-sort-by-most-recent-number)
>>   (setq gnus-thread-sort-functions '((not gnus-thread-sort-by-most-recent-number))))
>>
>> Though it's not by date...
>
> I overlooked that, I guess, and wrote the equivalent for date parsing
> while working on this.  That gets the initial sorting more or less
> right, but just the threads as pulled together based on message-ids;
> when threads with similar subjects are then collected together, the
> ordering in that phase doesn't come out the way I want it:
>
> E.  43380 30-Apr[  15:Stainless Steel] Re: Are the latest Oort features better 
> E.      43387 01-May<  31:Karl Eichwalder> 
> E.      43388 01-May<  10:Per Abrahamsen > 
> E.          43395 01-May[  13:Kai Großjohann ] 
> E.          43412 01-May[  21:Daniel Pittman ] 
> E.              43418 02-May[  12:Kai Großjohann ] 
> E.                  43419 02-May[  18:Daniel Pittman ] 
> E   43341 30-Apr[  12:Lars Bjønnes   ] Can topic parameters set group level?
> E       43365 30-Apr[  14:Josh Huber     ] 
> E.          43383 30-Apr[  22:Lars Bjønnes   ] 
> E.              43386 30-Apr[  28:Josh Huber     ] 
>  .  43406 01-May[  19:Oystein Viggen ] bug with imap in newest ognus snapshot
>  .      43408 01-May[  10:Simon Josefsson] 
>  .          43409 01-May[  11:Oystein Viggen ] 
>  .  43400 01-May[  17:Bill White     ] fast email downloading?
>  .      43417 02-May[  22:Kai Großjohann ] 
>
> In this case, I want the "Oort features" thread placed based on the
> highest number in all the gathered threads (43419), not the highest
> number in the first thread (43380).
>
> Ken

Re: wish list: thread-gathering sort options

[Ken Raeburn]

Truxton Fulton <trux@truxton.com> writes:
> I found a work-around that does the trick for me.  The thread
> gathering process gathers lower threads up to the higher thread.
> If this could be reversed (since the thread sorting order is also
> reversed), that would solve the problem.

That gets the groups of gathered threads into the proper order, but
wouldn't it put the thread with the latest messages first within each
group?  I think I'd want the threads within each gathered group to be
sorted by most-recent number or date too.

Still, it may better than the status quo.  Thanks for the suggestion,
I'll try it out.  A new thread-gathering function that does something
like:

     (reverse (gnus-gather-threads-by-subject (reverse arg)))

(or similarly for -by-references) should accomplish the same.

> I'm sure there's a better way, since this will only do good things
> for those of us with the most recent messages at the bottom of the
> buffer.

True...

Ken

Re: wish list: thread-gathering sort options

[Ken Raeburn]

I wrote:
> Truxton Fulton <trux@truxton.com> writes:
>> I found a work-around that does the trick for me.  The thread
>> gathering process gathers lower threads up to the higher thread.
>> If this could be reversed (since the thread sorting order is also
>> reversed), that would solve the problem.
> That gets the groups of gathered threads into the proper order, but
> wouldn't it put the thread with the latest messages first within each
> group?  I think I'd want the threads within each gathered group to be
> sorted by most-recent number or date too.

Looks like I was wrong.  I'm getting the threads within the gathered
groups in the correct order.  Yay!

Though I'm a little confused why it's working.  Probably I've just got
the wrong mental picture for how the gathering is working.  But that's
much less important than the fact that it's working.  :-)

Looks like I've got a new thread gathering function to use, for now:

    (defun kr-gnus-gather-threads-by-subject-reversed (threads)
      (reverse (gnus-gather-threads-by-subject (reverse threads))))

So, is it safe to use "nreverse" instead of "reverse" in
either or both of these cases?

And assuming this is in fact the right way to implement this reversal,
would it make sense to create yet another customization variable to
control this behavior, something like this (untested):

(defcustom gnus-summary-place-gathered-threads-last
  nil
  "*If non-nil, causes gathered threads to be retained in the original
position of the last of the threads gathered.  If nil, the gathered
threads are placed in the position of the first thread gathered."
  :group 'gnus-thread
  :type 'boolean)

...
       (if gnus-show-threads
           (if gnus-summary-place-gathered-threads-last
              (gnus-sort-gathered-threads
               (reverse
                (funcall gnus-summary-thread-gathering-function
                         (reverse
                          (gnus-sort-threads
                           (gnus-cut-threads (gnus-make-threads)))))))
             (gnus-sort-gathered-threads
              (funcall gnus-summary-thread-gathering-function
                       (gnus-sort-threads
                        (gnus-cut-threads (gnus-make-threads))))))
	 ;; Unthreaded display.
	 (gnus-sort-articles gnus-newsgroup-headers))))

Or maybe gnus-summary-thread-gathering-function should be allowed to
have an alternative form like '(reverse . some-function)?

Ken