Basically, make the "mu find .... --analyze" information available in
mu4e, through a function mu4e-server-last-query.
This is shows the query as the server saw it, as well as the parse
s-expressions. This can be useful to see how some query is interpreted.
Somewhere along the way, the body-txt and body-html fields were merged
into a single body field. Later, commit 8eac392221 ("guile: re-enable
the guile support") finally removed support for Field::Id::BodyHtml from
mu:c:get-field.
Unfortunately mu.scm and the documentation are still stuck in the past, so
update them. mu:body-txt is now a synonym for mu:body, and mu:body-html
always returns #f.
I wanted to add a mu:body test also for the rfc822.1 message, but there's
currently a bug where its body text is is duplicated (issue #2802), so the
test would fail.
It's stated to be US-ASCII with 7-bit encoding, but it contains the
UTF-8 character '—'.
Fixing the encoding very slightly changes the average size of messages
reported by mu:average, so adjust the new expected value.
`(add-hook 'mu4e-thread-mode-hook #'mu4e-thread-fold-apply-all)` doesn't
seem to fold threads. Did you mean `(add-hook 'mu4e-thread-mode-hook #'mu4e-thread-fold-all)`?
The json output (for mu-find etc.) just showed the converted sexp
output, including the clumsy emacs-style tstamps (for changed/date).
Add unix timestamps as well, which are easier to work with outside
emacs.
This handles #2770.
When files contain crm-separator (by default, some comma with option
whitespace), we cannot use mu4e-view-save-attachments since the emacs'
completion mechanism gets confused.
Luckily, we can still use mu4e-view-mime-part-action instead (which uses
numbers for files).
Single-threaded is the build-default, and seems to work well enough for
1.12.7, so remove the option to turn it off.
This is because build-options that influence such low-level/core
behavior are a pain to maintain.
