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.
