mu: cleanup server side; make sure not to loose 'personal' flag when
seeing same contact in non-personal context
mu4e: tweak the sorting algorithm a bit to take the personal flag into
account
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.
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.
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
Since the environment (and settings) can change, default to
re-calculating the maildirs when we need them. When you have so many
maildirs that this is slow, you can set mu4e-cache-maildir-list to
t (but be sure to read the docstring).
When contexts have been defined, automatically select one at startup --
either the first whose match-function returns non-nil, or simply the
first one.
Document this, too.
This way mu4e will intelligently shorten mailing list names which
contain dots:
(setq mu4e-mailing-list-patterns
'("\\([a-z0-9.]+\\)\.lists\.company\.com"))
Only issue a message. Refactor a bit.
This is for the use-case where the time to update is longer than the
period between updates -- e.g. you return from suspension/hibernation
and an old update process is still running.
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.
Added the customisation option 'mu4e-completing-read-function' which can
be used to choose which method of input-with-completion will be used by
mu4e. This variable is set to the function which mu4e will use.
By default, mu4e will use ido (via 'ido-completing-read'), but any
compatible completing-read function can be used instead. Interesting
choices would include 'helm-comp-read' for Helm-based completion, and
'completing-read' for the built-in basic completion system.
djcb
Hinrik Örn Sigurðsson
joost
Thierry Volpiatto
sabof
Titus von der Malsburg
Stuart Hickinbottom