Some mailing lists do _not_ set reply-to, see e.g.,
https://github.com/djcb/mu/pull/1278
In that case, use the 'List-Post' address instead, so the behavior is
the same (in mu4e) as for other mailing lists.
As discussed in #947, links need to be redefined for Org 9. This is
fixed in
[b885dd3](b885dd308e). At
the same time, `org-mu4e-store-and-capture` is still using
`org-mu4e-store-link` only, so it doesn't work in Org 9. Fix it
by interactively calling `org-store-link` instead.
When in single-window mode and invoking `mu4e-action-show-thread` from
the view buffer, stay in the headers buffer rather than going back to
the view buffer.
We got some errors when some of the key values exceeded the Xapian
maximum; in particular the message-id.
So make all the key-methods check, and truncate the message-id if
necessary.
Since cd649efb6b, opening an unread message first does a proc-move,
then proc-view.
Reason is that while we get the (:update ... ) from the move, that only
contains a skeleton message; we need the full view get images etc. This
means that we render the message _twice_.
Here we change add a flag for move to _not_ send the (:update ..), so
only the (:view ...) will trigger rendering of the message.
This allows to defer loading mu4e. That is, if we simply put in our
init file:
(with-eval-after-load 'org
(require 'org-mu4e))
then mu4e is only loaded if either we follow a mu4e link from an org
buffer or we call the autoloaded function `mu4e` to read our emails.
Storing org-mode links from mu4e buffers is unaffected by this change
since `org-mu4e-store-link` only applies from mu4e buffers.
Regarding the second, experimental part of org-mu4e.el about editing
mails with org-mode, I am not completely sure but I think it should
also be unaffected since it also seems to only apply from mu4e buffers.
The current threading algorithm is applied to the entire result of a query, even
if maxnum is specified, and then the result of the threading algorithm is
truncated to maxnum. The improves threading results by returning the entire
thread even when only a single message makes it into the top maxnum results.
This commit applies the threading algorithm to the related message set of the
maxnum-truncated query result instead of to the entire query result. For a given
set of messages, the set of messages which will share threads with any of the
original messages is exactly the related message sets. Put another way, either
any messages returned by the original query but removed by the maxnum truncation
will also be returned by the related message query, or they would not have been
needed anyway because they would not be members of any visible thread.
To maintain backward compatibility and allow threading to be used without
including related messages, the related message set is found for the threading
calculation, but any messages which would not have matched the original query
are then pruned, resulting in a superset of the truncated query, but a subset of
the untruncated query.
This does not improve (or degrade) the run time of a threading calculation when
maxnum is not set, but significant improves it when maxnum is set by making it
scale (roughly) linearly in terms of maxnum. On a maildir with ~200k messages
and maxnum set to 500 (the default), the run time of a threading calculation is
lowered from ~1m to ~0.1s.
Perform threading calculation on related set instead of entire result.
The current threading algorithm is applied to the entire result of a query, even
if maxnum is specified, and then the result of the threading algorithm is
truncated to maxnum. The improves threading results by returning the entire
thread even when only a single message makes it into the top maxnum results.
This commit applies the threading algorithm to the related message set of the
maxnum-truncated query result instead of to the entire query result. For a given
set of messages, the set of messages which will share threads with any of the
original messages is exactly the related message sets. Put another way, either
any messages returned by the original query but removed by the maxnum truncation
will also be returned by the related message query, or they would not have been
needed anyway because they would not be members of any visible thread.
To maintain backward compatibility and allow threading to be used without
including related messages, the related message set is found for the threading
calculation, but any messages which would not have matched the original query
are then pruned, resulting in a superset of the truncated query, but a subset of
the untruncated query.
This does not improve (or degrade) the run time of a threading calculation when
maxnum is not set, but significant improves it when maxnum is set by making it
scale (roughly) linearly in terms of maxnum. On a maildir with ~200k messages
and maxnum set to 500 (the default), the run time of a threading calculation is
lowered from ~1m to ~0.1s.
Oleh Krehel
Alex Murray
djcb
ibizaman
Cheong Yiu Fung
Eric Danan
Alberto Luaces
Nicolas Avrutin
Peter W. V. Tran-Jørgensen