When clicking "Accept" event, if the entry is new
it is not added to the Org file, besides having
gnus-icalendar-org-enabled-p set to true.
This modification changes that, so that a new entry
is added or an existing one is modified.
Being able to pipe through shell from the headers view is
convenient for some use cases, so wire it up to work.
Resolves#1752
Signed-off-by: Jerry Snitselaar <jsnitsel@redhat.com>
Seems there are problems compiling mu with XCode 11.6 (see build tests);
apparently because of libc++ being different from libstdc++.
clang++ builds works fine as long as we're using libstdc++.
If the user has wants to postpone clean-up we shouldn't lock the
indexer waiting for something that will never happen. Clear the flag
event though we are actually skipping cleanup.
If the user is scrolling and searching through the log buffer to see
what went wrong it gets very annoying having an update change things.
To avoid this wrap all buffer updating code in a save-excursion so
point is preserved.
mu4e-contact-rewrite-function was obsoleted in 1.4, but the entry in
NEWS.org entry, and the make-obsolete-variable call, referred to it as
mu4e-contacts-rewrite-function. (Should be "contact", not "contacts".)
- introduce private function mu4e~image-width-scale:
determine the width to use for proportional scaling based on the image width, height and the max
restrictions.
- use it in mu4e-display-image
When this function is declared const or pure, clang at -O1 or higher optimizes
away the call to mu_str_size_s() inside mu_str_size(), so that it ignores its
argument and returns whatever is in mu_str_size_s()'s static buffer.
Found when test-mu-str failed while testing an update of mu in OpenBSD's ports tree.
Ideally we should separate the log buffer creation code so this van be
done a bit more cleanly. For now however only set so-long-mode once
otherwise you end up spamming the messages with constant:
Changed to so-long-mode (from fundamental-mode) on account of line length. C-c C-c to revert. [36 times]
As the messages keep rolling in.
Implement a new message indexer consisting of a single-threaded scanner
and a multi-threaded indexer.
This allows for a number of optimizations as well as background
indexing, though this initial version should be behave similar to the
old indexer.