Rework the conversion from html to text; the functions doing that now
expect to receive one parameter, the message, and return the converted
message.
In the old way, the function got invoked in a buffer with html text, and
were expected to modify it to text. This old way is still supported for
backward compatibility.
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).
There were a handful places, primarily in the main menu, where the
word "focus" seemed to be used as a synonym for "context". This
changes all of those instances to "context".
As discussed in issue #544, it's possible to search for CJK text, as
long as you see the environment variable XAPIAN_CJK_NGRAM to non-empty
with Xapian >= 1.2.8.
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.
When we determine the drafts/refile/trash/sent folder, see if we can
find a context matching the particular message. If we find one, let-bind
the vars for that context before determining the folder.
This allows e.g for moving message to context-specific folder, rather
than the one for the current context - useful when dealing with headers
buffers with message belonging to different contexts.