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).
org-mime and potentially other users of `compose-mail' pass a parameter
`other-headers', an alist of the form ((symbol . string)).
`mu4e~compose-mail' sends this parameter to message-add-header, which
appears to expect a string instead. We therefore loop through
other-headers and instead pass a string to message-add-header for each
element of other-headers.
Seems the `mu4e-compose-type' is always nil when we enter the
compose (it is set when executing the pre-hooks though). It can be
useful in the compose buffer as well, so restore it.
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.
Replaces `message-kill-buffer' with `mu4e-message-kill-buffer'. This new
function is a wrapper around the original. It restores the window-layout
of mu4e after cancelling a message in mu4e-compose-mode.
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
Update mu4e-context-switch to not call the enter/leave functions when
'changing' to the current context. However, calling those functions (if
defined) can be force through a prefix arg. Document this.
Make mu4e-context-determine recognize 'policies', i.e. what to do when
no context matches. This part is WIP.
Make `global-mode-string' local in all buffers where we use it, so we
don't leak the "context" string outside mu4e.
Also add the context string to the compose buffer's modeline.
This fixes#740.
When user removes the In-Reply-To header, also remove the (hidden)
References header when sending the message, effectively making the
message appear at the top-level.
Mention in the doc, NEWS.
When `message-kill-buffer-on-exit` was set to nil mu4e would not close
the new frame. Closing the new frame should be independent of killing
the buffer. This patch corrects this.
(relates to #615)
