Different MIME configuration needs a fallback logic. Instead of looking
for the attachment "fname" in `("attachment" . (filename "fname"))` structure,
we find the same file name in `("mime-type" . (name . "fname"))` structure
by searching, since we don't know the MIME type beforehand.
Thanks @thierryvolpiatto.
Usurp more of the utils code than can be re-used without further dependencies in
helpers.
Split off specific parts in their own file.
After the helper/utils changes, update the rest of mu4e to take the changes into
account.
Split off the search functionality from mu4e-headers.el into a new
mu4e-search.el.
Clean up things a bit and create a minor mode in which to add the keybindings.
Enable this in main/headers/view.
mu4e reuses the default gnus-blocked-images, but sadly in the mu4e
context, the default (a function called gnus-block-private-groups) does
_not_ work (i.e., it never blocks).
Advise this function so it'll block for mu4e as well, and update the
docs.
Fixes: #2072.
Skip invisible text at BOL possibly hidden by
the end of another invisible overlay covering
previous EOL.
This patch affects people using mu4e-thread-folding-mode but change nothing
when using mu4e as it is.
This fixes the issue introduced by 50f6f539 where header navigation
would break when `visual-line-mode' was enabled. Previously,
`forward-line' was used in `mu4e-view-headers-next', which disregarded
visual lines and moved by logical lines, but this was changed to
`line-move', which moves by visual lines when `line-move-visual' is
non-nil (the default when `visual-line-mode' is enabled). Thus, when
the current header line was wrapped and a message was open in the
split view, `mu4e-view-headers-next' would move to the next visual
line in the headers buffer (the same message), and then jump back to
the start of the previous line, preventing switching to the next
message.
This would also throw off navigation when `mu4e-view-headers-next' was
used with a prefix argument, since it would move by visual lines and
not headers.
`line-move-visual' is therefore set to nil before using `line-move' to
prevent these issues.
This change is needed because forward-line doesn't honor this variable, more
generally visual lines.
Using `next-line` instead of `forward-line` allows this but it is more focused
on interactive use, so use `line-move` which handles visual lines without
warnings and return 0 or 1 just like `forward-line`.
This prevent deleting overlays added by third party packages working as well
with overlays in mu4e-headers e.g. thread-folding , and probably in mu4e
itself as well with future features. Also having a named overlay allows in
future features to modify any other overlays but these one.
As it is this patch doesn't modify the actual behavior.
Previously helm-comp-read-use-marked was bound also when completing on
a directory for saving attachments (when using a prefix argument). This
returned a list with the selected directory, which caused an error.
Dirk-Jan C. Binnema
Daniel Fleischer
Jakub Darul
Thierry Volpiatto
Étienne Deparis
Boris Glavic
Nacho Barrientos
DiGitHubCap
Anders Johansson