Mark some variables as use permanent-local so they'll survive a
major-mode change. Activate mu4e-view later, so hooks have some more
material to work with.
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.
