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.
In lazy-mode, we were skipping directories that did not change; however,
this didn't help for the case were users received new messages in big
maildirs.
So, add another check where we compare the ctime of message files with
the time of the last indexing operation. If it's smaller, ignore the
message-file. This is faster than having to consult the Xapian database
for each message.
Note that this requires in mu4e:
(setq mu4e-index-lazy-check t)
or
--lazy-check
as a parameter for 'mu index'.
It was a warning, but seems some users got it a lot (which is a sign
they're spending too much time indexing!); so let's demote it to a mere
message.
Issue #2778.
Try to update the query baseline if we're search for the favorite-query,
whether as a bookmark or an "organic" query, through a new function
mu4e--search-maybe-reset-baseline
Note that the query must string-match _exactly_, equivalence is not
enough.
Some cosmetic updates.
Fixes#2775.
