* mu4e/mu4e-lists.el (defgroup mu4e-lists): New group.
* mu4e/mu4e-list-archives.el: New file.
(defgroup mu4e-list-archives): New group.
(defcustom mu4e-list-archives-user-actions): New customizable
variable for locating online archive.
(mu4e-list-archives--get-recipients): New helper function for
getting all recipients of a mail.
(mu4e-list-archives-resolve-debbug): New function for resolving
archive url on debbug systems.
(mu4e-list-archives--resolve-namazu): New helper function for
resolving real archive url from namazu search page.
(defcustom mu4e-list-archives-resolve-namazu-search): New
customizable variable for disabling namazu resolution because it
incurs a url fetch.
(mu4e-list-archives-resolve-mailman-namazu): New function for
getting the namazu search url for mailman systems. This is as
close as possible without fetching any url.
(defconst mu4e-list-archives-actions): New constant for builtin
supported mailing lists.
(mu4e-list-archives-resolve): New function to resolve the concrete
url to the mailing list archive.
* mu4e/mu4e-actions.el (mu4e-actions-browse-list-archive): New
command for browsing the online archive of a mailing list.
(mu4e-actions-kill-list-archive): New command for putting the url
to the online archive of a mailing list onto the kill ring.
All these changes to avoid:
,----
| mu4e/meson.build:92: WARNING: Source item '/home/djcb/Sources/mu/build/mu4e/mu4e-meta.el' cannot be converted to File object, because it is a generated file. This will become a hard error in the future
`----
This is because we want to byte-compile a file we just before generated using
configure_file. This does not seem like a crazy thing, but meson threatens with
breaking the build at some point in the future.
So instead, we decide _not_ to compile this (very boring) file. But, users may
still have an older mu4e-meta.elc lying around, leading to confusion.
So, let's rename that file and we're golden.
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.
Use "_" as the title of that section so that it is less distracting
when sections are collapsed to get an overview of the library.
Using a separate section is useful because it reduces the risk of
accidentally into the middle of a library.
Placing two semicolons on an otherwise empty line helps to logically
"connect" the surrounding "paragraphs", which in (only) some cases
makes sense.
Previously the three paragraphs of the permission statement were not
connected to each other like this, which is perfectly fine. However
the preceding "This file is not part of GNU Emacs." line was connected
to the first paragraph, which does not make sense considering that the
latter is not connected two the second paragraph, which it relates to
more.
Once those two semicolons are gone, it also makes sense to remove
those from the second line.
When in single-window mode and invoking `mu4e-action-show-thread` from
the view buffer, stay in the headers buffer rather than going back to
the view buffer.
The old code directly hacked around with ido-read-directory to achieve
its smarts. However other completion methods are available so this
re-factors the code to use an appropriately predicated completing-read
with a new history variable which is just used for patch application.
This adds a variable mu4e-action-tags-completion-list, that contains a
list of commonly used tags to suggest as completion terms during a retag
actions.
Along the way, the retag action accepts as argument a comma-separated
list of +tag and -tag keywords, instead of a space-separated one,
removing the need to quote tags with spaces in them, and making it
consistent with the behaviour of completing-read-multiple.
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.
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.
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.
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.
Christoph Reichenbach
Dirk-Jan C. Binnema
Thierry Volpiatto
Ruijie Yu
Salman Mohammadi
Jonas Bernoulli
Thierry Volpiatto
Damien Garaud
Christophe Troestler
David C Sterratt
Alex Branham
Eric Danan
Alex Bennée
Abdo Roig-Maranges
Ævar Arnfjörð Bjarmason
Josiah Schwab
Jun Hao