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.
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