This commit adds a global variable
mu4e-compose-forward-as-attachment. To enable choosing forwarding
method on a per-message basis would probably require either:
• changing the mu server backend so that it distinguishes between
inline forwarding and forwarding as attachment;
• changing the mu server backend so that it doesn’t return attachments
at all and making both inline and as attachment forwarding via
MIME (and also making mu4e actually display MIME-enclosed inline
emails).
Some fields (eg. :attachments and :user-agent) require a full message
and are not supported in headers-mode. Document this and give a clearer
error message when they are added to `mu4e-headers-fields'.
Fixes issue #933.
Make the structures use for mu4e-bookmarks a defstruct, and update its
usage throughout the codebase. This makes it a bit easier to read and
extend.
Ensure that the old-style bookmarks are automatically converted.
Add two variables mu4e-index-cleanup and mu4e-index-lazy-check, which
correspond to mu index option --lazy-check and --nocleanup.
Extend the mu server protocol a bit to handle this.
The defaults keep things behaving as they done before.
mu4e was making a vain attempt to fontify the compose buffer; this
doesn't work because message (from which mu4e-compose-mode derives) uses
font-locking for that.
So, instead, remap the message-mode faces to the ones used for mu4e.
Add mu4e-view-fetch-url for fetching (downloading) URIs linked to in
e-mails. Add the 'f' keybinding for this, and document it.
Based on code by inigoserna.
Improve the contact-sorting algorithm, and make it better cooperate with
completion-at-point functions.
Also deal better with broken rewritten contacts, and document how
rewriting should done (docstrings and reference doc).
As discussed in issue #751, mu4e should tried to accommodate some
different ways of choosing the context.
We add a new policy `ask-if-none', that will only query the user if
there is no context yet; this is the new default for
mu4e-context-policy, i.e. what happens when entering the main view.
The default policy for mu4e-compose-context-policy is now `ask',
i.e. ask if none of the contexts match.
The idea is for the defaults to ask when we don't know a context, and we
can't determine one using the match functions; this is probably the
least confusing. When user gets annoyed by too many question, they can
tweak the behavior to their liking. I.e. 'ask questions first, shoot
later'
Document all of this.
set up the extra machinery for making sure emacs does not try to re-sort
our already-sorted contacts.... Also try to improve the sorting strategy
itself.
Allow setting a policy about what context to choose when starting mu4e
and composing a message. Basically:
When you have defined contexts and you start mu4e it decides which
context to use based on the variable `mu4e-context-policy';
similarly, when you compose a new message, the context is determined
using `mu4e-compose-context-policy'.
These policies can be one of the following:
- a symbol always-ask: unconditionally ask the user what context to pick
The other choices only apply if none of the context matches (i.e., if
none of the contexts' match-functions returns t:
- symbol ask: ask the user
- a symbol pick-first: pick the first context
- nil: don't change the context
This allows setting a custom face for the message body, e.g., if you
prefer a proportional font for the body:
(set-face-attribute 'mu4e-view-body-face nil :font "Liberation Serif-10")
with :thread-subject field, we attempt to only show one subject per
thread, somewhat like mutt does it.
the current implementation is straightforward, but does not take into
account whether the thread-subject is currently visible on the screen,
which is a bit tricky to implement
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.
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
Krzysztof Jurewicz
djcb
Allen
Christophe Troestler
Remco van 't Veer
Jun Hao
Daniele Pizzolli
Florian Lindner
Stephen Eglen
Alex Bennée
Foivos S. Zakkak
Oliver Dunkl
Oliver Dunkl
joost
Thierry Volpiatto
sabof