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.
This way mu4e will intelligently shorten mailing list names which
contain dots:
(setq mu4e-mailing-list-patterns
'("\\([a-z0-9.]+\\)\.lists\.company\.com"))
* mu4e/mu4e-view.el (mu4e-view-message-text):
When using `propertize' all properties added by `mu4e-html2text-command'
in html message are overwrited by `mu4e-view-body-face', so use here
`add-face-text-property' if available, otherwise behave as before and return
body unchanged.
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")
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.
It seems some tools try to interpret the filename of message files,
even though they shouldn't:
"Do not try to extract information from unique names."
In particular, they seem to interpret the first part of the name (before
the first dot) as the # of seconds since the Unix epoch (ie.,
time(NULL)). That's not what mu/mu4e put there.
So, let's conform a bit more to the expected filename (as per the
maildir spec), so we're not confusing those tools.
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)
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
Don't use our own URL-matching regexp, use the one that emacs provides
(in thing-at-point), which is a bit more general, and seems to better
handle some URLs.
When sending org mode mail, both the text/html and text/plain parts
contained the HTML version of the mail, instead of just the text/html
part. This patch puts the raw-body (org format) in the text part, and
the html with replaced images in the html part.
- The queue-related actions of `mu4e~main-view-real` have been extracted
to their own `mu4e~main-view-queue` method.
- The queue toggling action now has the word "currently" to easily.
distinguish between the current state and the toggle (e.g., "currently
queued" instead of just "queued").
- The "[f]lush queued emails" is only visible if there is at least 1
email in the queue.
- The number of emails in the queue is visible in the flushing
action (e.g., "[f]lush 10 queued emails").
This example shows how to archive and mark a message as read which emphasizes
the importance of order in tagging a message before anything else due to the
implementation of tagging (since it currently uses 'sed').
Previously, the behavior of mu4e-view-headers-next-unread was that the cursor moved in the headers view but did not change the highlight nor the message in the view buffer. This patch updates the function to also select the message in the view buffer which appears to also highlight the message correctly in the header view.
This allows to re-tag a message in a mark action.
Two examples of what one can do with this stuff:
1. G-mail archiving:
(archive
:char "a"
:prompt "archive"
:show-target (lambda (target) "archive")
:action (lambda (docid msg target)
(mu4e~proc-move docid nil "-N")
(mu4e-action-retag-message msg "-\\Inbox")))
2. Tagging:
(tag
:char "g"
:prompt "gtag"
:ask-target (lambda () (read-string "What tag do you want to add?"))
:show-target (lambda (target) target)
:action (lambda (docid msg target)
(mu4e~proc-move docid nil "-N")
(mu4e-action-retag-message msg (concat "+" target))))
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.
:get-target is split into:
- :ask-target (run once per bulk operation)
- :dyn-target (run once per message)
A side benefit is that the existence of the target of a move is not
checked for every message when doing bulk moves.
This is a bug fix. Previously, recomputing was done only for refile,
which is wrong: trash target can also be dynamic, and we want to allow
the user to configure more dynamic targets.
This commit puts all what defines a mark (how to display, how to handle
targets, what action to apply, ...) in a single entry of a list. The list
is stored in a variable.
This should allow for customization of marks.
In the headers-view, allow for movig to next and previous
unread/untrashed messages using tab/backtab.
Built on top of the convenience function mu4e-headers-find-if-next.
Update docstrings.
When HTML emails contain references to remote images, retrieving these images
leaks informationo. For example, the sender can see when I openend the email
and from which computer (IP address). For this reason, it is preferrable to
not retrieve images.
In the case of encrypted and signed messages the signature field's
details box did not work due to missing flags to the mu verify command.
This commit fixes this issue.
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
This patch fixes the attachment extraction (open, save, temp) when using
`mu4e`. `mu4e` used to not notify the mu-server about the
mu4e-decryption-policy. As a result mu-server did not decrypt the
attachments for extract, open, or temp.
