Now, when going to a message with certain message-id, do open a headers
buffer as well. This way, message opened this behave just like an other
message, and can be delete, flagged etc.
As a bonus, you get the whole message thread for a given
message (depending on settings)
mu4e-view-message-with-message-id now does a search and
mu4e-headers-search allow for some extra actions to open a specific
message in a hook function.
Clean up the creation of html files a bit, and automatically clean them
up after a short while, so we don't clutter /tmp.
Refactor the html-generating actions, so we don't repeat ourselves too
much.
This was merged in as part of pull request #718 but changed to a more
general facility in 7716e00.
It's fantastic that we have the more general hook facility for any
search, but the primary use-case I had for the bookmark hook can't be
satisfied by the more general mu4e-headers-search-pre-hook.
The reason I added this hook was to emulate the folders I used in
Icedove as mu4e bookmarks. E.g. some folders are threaded, others are
not. By default mu4e only allows you to set this globally via options
like mu4e-headers-show-threads.
So I have a mu4e-headers-search-bookmark-hook which is basically a long
line of cond statements like:
((string-equal expr "NOT flag:trashed AND date:365d..now AND (flag:flagged)")
(setq mu4e-headers-show-threads nil)
(setq mu4e-headers-include-related nil)
(setq mu4e-headers-skip-duplicates t)
(setq mu4e-headers-results-limit 500))
For this to work properly it's critical that the hook doesn't execute on
any search, but *only* those where we enter it via the bookmark.
As an example, I have a "b+" search which finds messages I've flagged,
most of my searches have related & threading turned on, but for that
search I only want to show the specific messages I've flagged, so the
hook turns both of those settings off before executing the search.
But I might still want to change my mind and look at the related
messages as threads by pressing P and then W. This works with the
mu4e-headers-search-bookmark-hook because it only executes when we get
the search via a bookmark.
But it doesn't work with the mu4e-headers-search-pre-hook because when I
toggle the setting my settings hook (which matches the search executed
by the bookmark) will just turn it back off again.
Perhaps there's some clever way to know if we're getting to the
mu4e-headers-search-pre-hook via the bookmark that I've missed. But if
there isn't I need a hook that works like this.
Though it shouldn't, some users have
mu4e-compose-complete-ignore-address-regexp at nil, which gives errors
with the new contacts code. Be a bit more tolerant.
Add `mu4e-compose-resend` to the menus in the headers and view
modes. Don't add a shortcut, as it's a fairly rarely needed feature, and
might be confusing if invoked accidentally.
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.
Explicitly add the (html 5) <meta charset ...> for UTF-8; not all
browsers default to UTF-8 and could show the class "Â" characters when
interpreting UTF-8 as ISO-8859-1.
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.
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.
Add `mu4e-view-toggle-html' for toggling between html and text display
of messages (when available); keybinding 'h'. Document this.
The new default keybinging for mu4e-view-toggle-hide-cited becomes '#'.
Some mails were not showing; this was because they had a short (useless)
text part and an html-part with the content. However, the short part was
still too big to fail our heuristic in
mu4e-view-html-plaintext-ratio-heuristic
Set it to 5 instead. This fixed#743, though not the more general case.
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.
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).
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 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.
Let's not spam the poor sods who own foo.com and bar.com, or home.com
etc. Went through the various examples and changed them to use
example.com or subdomains of example.com where appropriate, even when
the domain or TLD didn't exist (yet!) for completeness.
See-Also: https://tools.ietf.org/html/rfc2606
Define mu4e-context - a structure with settings and enter/leave
functions for contexts, and some functions for switching between
contexts and auto-detecting them.
I'm using this for a rather nasty hack. When I open different bookmarks
in the mu4e-main view I want to set options for them, currently just
tweaking:
* mu4e-headers-show-threads
* mu4e-headers-include-related
* mu4e-headers-skip-duplicates
* mu4e-headers-results-limit
This is because some of my searches are *really* expensive when I
include related threads (huge batches of cron-generated E-Mails), but
some aren't. I couldn't find another way to do this. Using
mu4e-headers-mode-hook doesn't work, because we don't have access to the
search (just a variable showing the last search).
Also maybe we should be passing the actual key chord for the bookmark
here. I don't care since I look up the search string that'll be executed
and go from there, but maybe that interface would make more sense.
But whatever, this works for me, and solves a real use-case.
Right now we have this for showing the status of messages, e.g. whether
it has an attachment etc. But not for the "d", "D" etc. in the leftmost
column of the headers view.
This adds support for that, while bending over backwards to ensure that
anyone who's customized this in the past won't have their customizations
broken, i.e. like `mu4e-headers-trashed-mark` we can set this to a cons
cell of basic/fancy characters, but we also continue to support this
just being a string for existing users.
The next patch in this series adds a couple of non-ASCII characters to
be used for the trash / delete mark.
Because this was a lambda C-h m would just show "??" instead of the
function name, and the documentation would be really confusing since it
showed the deparsed lambda function instead of the function name being
called.
Fix this by refactoring both the view & headers [ and ] functions into
named functions, and make their shared logic new internal
mu4u~{headers,view}-* functions.
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.
