Reverse thread sorting by most recent number

Reverse thread sorting by most recent number

[Christoph Groth]

Hello,

I have set gnus-thread-sort-functions to
'(gnus-thread-sort-by-most-recent-number) and this works as it should.

Now I would like to reverse the sorting order so that the order of
threads is consistent with the chronological order of messages within a
thread.

I defined a function

(defun my-thread-sort-by-most-recent-number-reversed (h1 h2)
  "Sort threads such that the thread with the most recently arrived article comes last."
  (< (gnus-thread-highest-number h1) (gnus-thread-highest-number h2)))

that should return the negation of
gnus-thread-sort-by-most-recent-number, but setting
gnus-thread-sort-functions to it does not seem to work.  Single messages
are sorted as expected, and new messages tend to appear at the back of
the buffer, but in some cases threads with new messages are stuck above
older ones.  The sorting order of threads is clearly not the opposite of
the one given by gnus-thread-sort-by-most-recent-number.

I have no clue why Gnus behaves like this...  Anyone has an idea?

Cheers
Christoph

_______________________________________________
info-gnus-english mailing list
info-gnus-english@gnu.org
https://lists.gnu.org/mailman/listinfo/info-gnus-english

Re: Reverse thread sorting by most recent number

[Fraga, Eric]

I cannot help you directly but I have the following various settings
which together give me what I want:

(setq gnus-sort-gathered-threads-function 'gnus-thread-sort-by-date
      gnus-subthread-sort-functions '(gnus-thread-sort-by-date)
      gnus-thread-sort-functions '(gnus-thread-sort-by-date gnus-thread-sort-by-total-score)
      )

What I want may differ from your needs but maybe playing with these
could give you the desired outcome.

HTH,
eric

-- 
Eric S Fraga via Emacs 27.0.50 & org 9.3 on Debian bullseye/sid

_______________________________________________
info-gnus-english mailing list
info-gnus-english@gnu.org
https://lists.gnu.org/mailman/listinfo/info-gnus-english

Re: Reverse thread sorting by most recent number

[Christoph Groth]

Christoph Groth wrote:

> (...)  Single messages are sorted as expected, and new messages tend
> to appear at the back of the buffer, but in some cases threads with
> new messages are stuck above older ones.  The sorting order of threads
> is clearly not the opposite of the one given by
> gnus-thread-sort-by-most-recent-number.

To debug, it would be helpful to be able to request the thread data
structure (in the sense of gnus-sum.el) of the current thread.  I.e. the
data structure that one can pass to gnus-thread-highest-number for
example.

The function gnus-make-threads returns a list of all the threads in the
summary buffer, but I haven't found a way to get the current thread
only.

Thanks,
Christoph

_______________________________________________
info-gnus-english mailing list
info-gnus-english@gnu.org
https://lists.gnu.org/mailman/listinfo/info-gnus-english

Re: Reverse thread sorting by most recent number

[Christoph Groth]

Christoph Groth wrote:

> I have set gnus-thread-sort-functions to
> '(gnus-thread-sort-by-most-recent-number) and this works as it should.
>
> Now I would like to reverse the sorting order so that the order of
> threads is consistent with the chronological order of messages within
> a thread.

I managed to solve the problem myself and reply here for reference.  It
turns out that the threads that were sorted incorrectly were those with
missing messages.

For

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

to work, i.e. for chronological sorting of threads according to the most
recent article, I also need to enable sparse threads:

(setq gnus-build-sparse-threads 'more)

Otherwise, the determination of the most recent number seems to be
hindered by missing articles.  However, if
gnus-thread-sort-by-most-recent-number is not reversed, it seems to work
also without sparse threads.

After 20 years of using Gnus I'm still amazed how cool it is and how
arcane...

I guess that this problem would deserve being "fixed" in some way
(i.e. by clarifying documentation).  Should I write to the emacs-devel
mailing list?  Or is this issue not important enough?

Christoph

_______________________________________________
info-gnus-english mailing list
info-gnus-english@gnu.org
https://lists.gnu.org/mailman/listinfo/info-gnus-english