[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: rmail threading
From: |
Eli Zaretskii |
Subject: |
Re: rmail threading |
Date: |
Thu, 02 Sep 2021 09:43:59 +0300 |
> 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.