Re: rmail threading

[Eli Zaretskii]

> From: Richard Stallman <rms@gnu.org>
> Cc: emacs-devel@gnu.org
> Date: Wed, 01 Sep 2021 23:37:51 -0400
> 
> This suggests we should have a convenient way to make multiple
> summaries of a single Rmail buffer, and keep them in parallel.
> What do you think of that?

That'd help, yes.  Still, the need to switch between different summary
buffers is less convenient, IMO.

>   > > A summary in Rmail doesn't stop you from looking at messages not
>   > > included in it.  I do that frequently.
> 
>   > Can you tell how do you do that?
> 
> If you have the Rmail buffer selected, the summary does not affect the
> ordinary Rmail commands.  They move through the whole file unaffected
> by the summary.

Yes, of course.  But that means you move by single message, which is
very inconvenient when you search for something.  M-s could help, but
M-s still leaves you looking at the inbox through a single-message
loophole.

>   > And I have one additional question about your request to have a
>   > summary-by-thread: is it okay to request that the user first sorts the
>   > messages by date (C-c C-s C-d), before summarizing the thread?
> 
> That would be a pain in the neck for me.  I don't want to reorder
> RMAIL file.

Too bad.

> If you go through all the messages making a Lispy data structure that
> records the most important header fields of each, and its message
> number, it would be pretty easy to sort that data structure and then
> find the threads in it.  Then you could display the thread summary
> either by send order or by order in the Rmail file.

Yes, that's more or less what Gnus does.  So I think the best way of
doing that would be to borrow the code from Gnus.  I hoped to avoid
that complexity, including the need to process all the threads before
one can walk a single thread.  I usually leave in INBOX old messages
that I need to consult frequently, so my INBOX file is very large, and
processing all of it for threads could take a while.