* mu4e/mu4e-view.el (mu4e-view-message-text):
When using `propertize' all properties added by `mu4e-html2text-command'
in html message are overwrited by `mu4e-view-body-face', so use here
`add-face-text-property' if available, otherwise behave as before and return
body unchanged.
This allows setting a custom face for the message body, e.g., if you
prefer a proportional font for the body:
(set-face-attribute 'mu4e-view-body-face nil :font "Liberation Serif-10")
Only issue a message. Refactor a bit.
This is for the use-case where the time to update is longer than the
period between updates -- e.g. you return from suspension/hibernation
and an old update process is still running.
It seems some tools try to interpret the filename of message files,
even though they shouldn't:
"Do not try to extract information from unique names."
In particular, they seem to interpret the first part of the name (before
the first dot) as the # of seconds since the Unix epoch (ie.,
time(NULL)). That's not what mu/mu4e put there.
So, let's conform a bit more to the expected filename (as per the
maildir spec), so we're not confusing those tools.
The core dump only seems to occur if mu4e-headers-include-related is
set to t.
Apparently, std::string's c_str() method is confusing to many
people, c.f.
http://stackoverflow.com/questions/22330250/how-to-return-a-stdstring-c-str
The answer seems to be that the pointer c_str() returns may not be
valid past the current statement; returning it, or even using it
subsequently can have you sending a wild pointer into e.g. g_strdup().
In short, it seems idioms like this are okay:
return g_strcmp0 (s1.c_str(), s2.c_str()) < 0;
Whereas idioms like this are not:
const char *msgid (iter->msgid().c_str());
return msgid ? g_strdup (msgid) : NULL;
At least in my environment by the time we get to g_strdup() the
pointer returned by c_str() is wild and points at garbage. Since
g_strdup() returns NULL if passed NULL, it seems collapsing it into a
single line is not only possible but necessary.
I've looked at all of the calls to c_str() in mu and it appears to
me this was the one remaining one that was bad.