Make mu4e-view-toggle-html _not_ toggle the global value of of
mu4e-view-prefer-html, but only the current one.
Make the link map 'permanent', so it survives the buffer changes when
refreshing. This fixes issue #904.
The kill ring fills up with lines like:
C: 0/1 B: 28/29 M: +0/0 *0/0 #0/0 S: +2/2 *1/1 #0/0
when using mbsync or another tool using carriage return for progress.
This is a follow-up to my pull request #895 which fixes another bug in
pull request #831 (d16957d).
The code to write out the attachments would never work, for what it's
worth it's clear from the issue I fixed in #895 that the codepath had
never been executed as-is.
It would find the attachments and try to write them out to /tmp/, just
that, no /tmp/NAME, just the directory itself. That would yield an
error of trying to write to a directory.
Fix that, now we create a temporary name as a function of the
attachment and both save it and extract it.
This makes the mu4e-action-view-in-browser function finally work for
me. It'll now write out the attachments to /tmp, and rewrite the HTML
so that I'll see the attachments in my browser.
The mu4e-message-field function was called in a way that would never
work, fix that by calling it correctly.
There's the additional follow-up TODO here that the mu4e-message-field
function itself should probably die on this sort of invocation, but I
don't know enough about elisp idioms to know how that should look.
This fixes my issue #894.
Make the structures use for mu4e-bookmarks a defstruct, and update its
usage throughout the codebase. This makes it a bit easier to read and
extend.
Ensure that the old-style bookmarks are automatically converted.
Add two variables mu4e-index-cleanup and mu4e-index-lazy-check, which
correspond to mu index option --lazy-check and --nocleanup.
Extend the mu server protocol a bit to handle this.
The defaults keep things behaving as they done before.
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.
This patch improves the behavior of mu4e-action-show-thread. This
action now leaves the point on the message where the action was invoked,
which helps prevent losing ones' place in a long thread. When invoked
in view mode, it continues to display the message that was being viewed,
instead of returning to a header-only view.
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.
