Add two new customization variables:
mu4e-index-update-error-continue
mu4e-index-update-error-warning
With these, we can configure what happens when the mail-retrieval
program finishes with a non-zero exit code.
Make the default to warn but continue; it seems quite some users got
bitten by the old behavior of not updating after an error (which may
only be a pseudo-error). offlineimap/mbsync do not document their exit
codes very well, unlike fetchmail.
Also update manual for this.
:get-target is split into:
- :ask-target (run once per bulk operation)
- :dyn-target (run once per message)
A side benefit is that the existence of the target of a move is not
checked for every message when doing bulk moves.
This is a bug fix. Previously, recomputing was done only for refile,
which is wrong: trash target can also be dynamic, and we want to allow
the user to configure more dynamic targets.
This commit puts all what defines a mark (how to display, how to handle
targets, what action to apply, ...) in a single entry of a list. The list
is stored in a variable.
This should allow for customization of marks.
In the headers-view, allow for movig to next and previous
unread/untrashed messages using tab/backtab.
Built on top of the convenience function mu4e-headers-find-if-next.
Update docstrings.
When HTML emails contain references to remote images, retrieving these images
leaks informationo. For example, the sender can see when I openend the email
and from which computer (IP address). For this reason, it is preferrable to
not retrieve images.
In the case of encrypted and signed messages the signature field's
details box did not work due to missing flags to the mu verify command.
This commit fixes this issue.
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
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.