This reverts commit 6e9b9ad2d0.
Unfortunately the reverted commit breaks the Signature field for
encrypted and, at the same time, signed messages.
TODO: details button in the Signatures field does not work for such
cases because the signature is encrypted.
Conflicts:
lib/mu-msg-part.c
Add a decryption field of the form
Decryption: 2 part(s) decrypted 1 part(s) failed
Meaning that 2 encrypted mime parts where successfully decrypted and 1
part failed. Note that the number 2 refers to the number of
successfully decrypted mime parts and not the number of successfully
decrypted encryptes multiparts, i.e., if an encrypted multipart
contains 4 parts and decryption is successful the field will be
Decryption: 4 part(s) decrypted
TODO: Add details button listing the names and indexes of the
decrypted (or not) mime-parts
Pull request #483 does not handle encrypted multiparts properly. It
used to just verify the signature and not process the parts of the
multipart. This commit resolves this issue.
Additionally it did not index attachments properly and in the case of a
multipart directly containing more than one multiparts resulted on non
unique indexing of attachments/parts. This commit resolves this issue
as well.
This patch fixes the attachment extraction (open, save, temp) when using
`mu4e`. `mu4e` used to not notify the mu-server about the
mu4e-decryption-policy. As a result mu-server did not decrypt the
attachments for extract, open, or temp.
After a multipart/encrypted part gets decrypted the result is usually a
`multipart/mixed` part (see enigmail).
Before this commit mime multiparts where handled only by
`g_mime_message_foreach`. As a result the decrypted mime multiparts
where not processed.
This patch handles mime multiparts explicitly by removing the
`g_mime_message_foreach` invocations. This might come at the cost of
reduced maintainability, in the case of radical gmime changes. However,
gmime is pretty stable and that scenario is highly unlikely.
TODO: After decryption make any attachments available
When the root set contains only one empty container with one child
first promote the child container to the root set and only then
remove the empty parent container so that the root set never goes
empty.
Also make mu_container_splice_children() do only one thing, that is
promote one container's children to be another container's siblings.
The resultant childless container is no longer removed by this
function.
Fixes#460.
This test reproduces a regression introduced by commit 97101f1f82
("mu: Prune empty container when an only child gets promoted to the
root set").
When the results of a mu-find query contain only a one thread:
$ mu find --threads --fields 'd s' ''
Sat 09 Aug 2014 07:00:00 PM CEST [mu4e] Test Message
`-> Sat 09 Aug 2014 08:30:00 PM CEST Re: [mu4e] Test Message
... and we narrow down the query in such a way that the root message
gets excluded, then a crash occurs:
$ mu find --threads --fields 'd s' '' date:2014-08-09/20:00..2014-08-09/21:00
**
ERROR:mu-container.c:117:mu_container_append_siblings: assertion failed: (c)
Aborted (core dumped)
Reported-by: Josiah Schwab <jschwab@gmail.com>
Traverse the container tree depth first and for each container find
the node in the subtree rooted at this container which comes first in
the descending sort order. Remember it as the subtree leader. Then,
while sorting siblings, compare their subtree leaders instead of the
sibling containers themselves.
IOW, make threads containing the newest message float to the top when
sorting by date in the descending order.
There is no significant performance degradation when sorting a
mailbox with ~16k messages:
$ mu find maildir:/INBOX | wc -l
16503
Current state:
$ perf stat --event=task-clock --repeat=10 -- \
mu find maildir:/INBOX -n 1 -t > /dev/null
Performance counter stats for 'mu find maildir:/INBOX -n 1 -t' (10 runs):
1231.761588 task-clock (msec) # 0.996 CPUs utilized ( +- 1.02% )
1.236209133 seconds time elapsed ( +- 1.08% )
With patch applied:
$ perf stat --event=task-clock --repeat=10 -- \
mu find maildir:/INBOX -n 1 -t > /dev/null
Performance counter stats for 'mu find maildir:/INBOX -n 1 -t' (10 runs):
1459.883316 task-clock (msec) # 0.998 CPUs utilized ( +- 0.72% )
1.462540088 seconds time elapsed ( +- 0.77% )
This implements https://github.com/djcb/mu/issues/164.
This reverts commit c7b28419ab.
The reverted change fails to sort threads correctly when there is an
empty container, serving as a parent to orphan messages, in the thread
tree as demonstrated by the test in commit f49296759e ("tests:
threads: Test if orphan message promotes its thread").
Also, the reverted commit introduces a performance hit. The time it
takes to sort threads has increased roughly by a factor of 4.
Current state:
$ perf stat --event=task-clock --repeat=10 -- \
mu find maildir:/INBOX -n 1 -t > /dev/null
Performance counter stats for 'mu find maildir:/INBOX -n 1 -t' (10 runs):
4967.692519 task-clock (msec) # 1.000 CPUs utilized ( +- 0.14% )
4.969247128 seconds time elapsed ( +- 0.14% )
With the reverted patch applied:
$ perf stat --event=task-clock --repeat=10 -- \
mu find maildir:/INBOX -n 1 -t > /dev/null
Performance counter stats for 'mu find maildir:/INBOX -n 1 -t' (10 runs):
1231.761588 task-clock (msec) # 0.996 CPUs utilized ( +- 1.02% )
1.236209133 seconds time elapsed ( +- 1.08% )
The benchmark was ran on a maildir with ~16k messages:
$ mu find maildir:/INBOX | wc -l
16503
When processing multiple lines for a subject line separated by TAB
characters we don't want to eliminate the control character totally but
replace it with a simple space. I've left the control handling as before
for non-white space characters.
Signed-off-by: Alex Bennée <alex@bennee.com>
it seems g_locale_from_utf8 behaves a bit differently on bsd/macosx,
causing a segfault (but when run under gdb!). this code path was hit
for messages with encoding problems in non-utf8 locales
at macos this function /seemed/ to massively leak, when looking at the
valgrind output on macos (but not linux). with this update, this
leak(?) is gone.
