As discussed in #947, links need to be redefined for Org 9. This is
fixed in
[b885dd3](b885dd308e). At
the same time, `org-mu4e-store-and-capture` is still using
`org-mu4e-store-link` only, so it doesn't work in Org 9. Fix it
by interactively calling `org-store-link` instead.
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.
Since cd649efb6b, opening an unread message first does a proc-move,
then proc-view.
Reason is that while we get the (:update ... ) from the move, that only
contains a skeleton message; we need the full view get images etc. This
means that we render the message _twice_.
Here we change add a flag for move to _not_ send the (:update ..), so
only the (:view ...) will trigger rendering of the message.
This allows to defer loading mu4e. That is, if we simply put in our
init file:
(with-eval-after-load 'org
(require 'org-mu4e))
then mu4e is only loaded if either we follow a mu4e link from an org
buffer or we call the autoloaded function `mu4e` to read our emails.
Storing org-mode links from mu4e buffers is unaffected by this change
since `org-mu4e-store-link` only applies from mu4e buffers.
Regarding the second, experimental part of org-mu4e.el about editing
mails with org-mode, I am not completely sure but I think it should
also be unaffected since it also seems to only apply from mu4e buffers.
When we render URLs like https://gnu.org/[1] right-clicking on them in
e.g. GNOME Terminal will also copy the "[1]" as well as the URL,
inserting zero-width-space[1] between the two avoids this.
I know about "g" (mu4e-view-go-to-url), but sometimes I want to open a
URL in a different browser, or copy it into a non-Emacs program. This
makes that easier. I think this improves the UI at a very trivial cost
to users that don't care about this use-case.
I could make this configurable, but unless someone vehemently objects
to this I don't see the point of not just making it the default.
In GNOME Terminal a ZWS is rendered simply as a space, and
copy/pasting works as expected, but in Emacs's GTK GUI there's no
space between the two.
This was initially a plain ASCII space character, but djcb preferred a
ZWP, and this works as well.
1. https://en.wikipedia.org/wiki/Zero-width_space
Define the view-mode (gnus or internal) just before it's needed. This
ensures that (when in gnus mode) it's really a gnus-article-mode
derivative, so more of the gnus specifics work.
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.
Re-use `mu4e-headers-thread-orphan-prefix' for the prefix for the
first sibling in the orphan thread and add
`mu4e-headers-thread-single-orphan-prefix' as the prefix of single orphans.
When we mark a message as read, we get an (:update ... ) with the
marked-as-read message (ie., moved from new/ to cur/).
The (:update ...) however does _not_ include extracted images etc.; so
images in unread message would not be visible at that time. To fix this,
to another (:view ...) and extract the images etc.
Thanks to tangxinfa for pointing this out.
djcb
Cheong Yiu Fung
Eric Danan
Alberto Luaces
Ævar Arnfjörð Bjarmason
Alex Bennée
Alex Branham
Marcelo Henrique Cerri