The new notmuch-search-hide-excluded option allows users to configure whether
to show or hide excluded messages (as determined by search.exclude_tags
in the local notmuch config file). It defaults to true for now to maintain
backwards-compatibility with how notmuch-{search,tree} already worked.
New commands notmuch-search-toggle-hide-excluded and
notmuch-tree-toggle-exclude have also been added. They toggle the value
of notmuch-search-hide-excluded for the search in the current search or
tree buffer. It's bound to "i" in the respective keymaps for these
modes.
Lastly I've amended some calls to notmuch-tree and notmuch-unthreaded
which didn't pass through the buffer local value of
notmuch-search-oldest-first (and now notmuch-search-exclude).
Examples of where I've done this include:
+ notmuch-jump-search
+ notmuch-tree-from-search-current-query
+ notmuch-unthreaded-from-search-current-query
+ notmuch-tree-from-search-thread
A new test file for Emacs has been added which covers the usage of the
new `notmuch-search-hide-excluded' option and interactively hiding or
showing mail with excluded tags. These test cover the basic usage of
the `notmuch-search-toggle-hide-excluded' command in notmuch-search,
notmuch-tree and notmuch-unthreaded searches. These tests also cover
the persistence of the current value of the hide-excluded mail option
as a user switches from between these different search commands.
[1]: id:87ilxlxsng.fsf@kisara.moe
Amended-by: db, fix indentation in T461-emacs-search-exclude.sh
Today someone asked me the (reasonable) question of how much
performance impact there is from synching tags to maildir flags. It
turns out it is noticeable, about a 50% overhead compared to
non-synched tags (according to these tests). In practice I don't know
if it's a big problem for users, since I don't know what fraction of
tagging operations involve "special" tags.
Some people (e.g: me) prefer to read their email with threaded
representation by default.
Without this commit, I have to run "notmuch-search" (autoloaded)
first to get "notmuch-tree" loaded.
Previously we both found a database and returned a message saying that
the database could not be found (along with a success code). This
change should prevent spurious error output.
Duplicate bug reported in id:87wmtvcor5.fsf@alyssa.is
The error message is nonsense, because notmuch config list actually
includes the database in those two cases.
Currently the --to/--cc/--bcc options add "user@example.com, " to the
message headers, with the the unnecessary ", " separator after the
last address, regardless of how many addresses are being added.
This used to be fine, but with recent emacs mm, trying to send the
email with the trailing commas leads to prompt:
Email address looks invalid; send anyway? (y or n)
Fix this by only adding the commas between addresses, avoiding the
trailing commas.
qsort(3) does not promise stability, and recent versions of glibc have
been showing more unstable behaviour [2]. Michael Gruber observed [1] test
breakage due to changing output order for message properties.
We provide a sorting order of (key,value) pairs that _looks_ stable by
breaking ties based on value if keys are equal. Internally there may
be some instability in the case of duplicate (key,value) pairs, but it
should not be observable via the iterator API.
[1]: id:CAA19uiSHjVFmwH0pMC7WwDYCOSzu3yqNbuYhu3ZMeNNRh313eA@mail.gmail.com
[2]: id:87msv3i44u.fsf@oldenburg.str.redhat.com
According to emacs upstream [1], we can't expect overlay invisibility
and images to get along. This commit uses the previously stashed
undisplayer functions to actually remove the images from the buffer.
When the image is toggled, it is essentially redisplayed from scratch,
using the previously stashed redisplay data.
[1]: https://lists.gnu.org/archive/html/emacs-devel/2023-08/msg00593.html
This data will be used to redisplay an image that is hidden by
deleting it from the buffer. We cannot easily delay until the image
is hidden, as we won't have the original data at that point.
For some kinds of MIME parts (at least images), our trickery with
overlays will not work, so save the more drastic function created by
Gnus that actually deletes the part from the buffer. In an ideal world
we would return this function as (part of) a value, but here the call
stack is too complicated for anything that simple, so we stash it in
the part plist and rely on that being preserved (unlike the mm handle,
which is transient).
