This was merged in as part of pull request #718 but changed to a more
general facility in 7716e00.
It's fantastic that we have the more general hook facility for any
search, but the primary use-case I had for the bookmark hook can't be
satisfied by the more general mu4e-headers-search-pre-hook.
The reason I added this hook was to emulate the folders I used in
Icedove as mu4e bookmarks. E.g. some folders are threaded, others are
not. By default mu4e only allows you to set this globally via options
like mu4e-headers-show-threads.
So I have a mu4e-headers-search-bookmark-hook which is basically a long
line of cond statements like:
((string-equal expr "NOT flag:trashed AND date:365d..now AND (flag:flagged)")
(setq mu4e-headers-show-threads nil)
(setq mu4e-headers-include-related nil)
(setq mu4e-headers-skip-duplicates t)
(setq mu4e-headers-results-limit 500))
For this to work properly it's critical that the hook doesn't execute on
any search, but *only* those where we enter it via the bookmark.
As an example, I have a "b+" search which finds messages I've flagged,
most of my searches have related & threading turned on, but for that
search I only want to show the specific messages I've flagged, so the
hook turns both of those settings off before executing the search.
But I might still want to change my mind and look at the related
messages as threads by pressing P and then W. This works with the
mu4e-headers-search-bookmark-hook because it only executes when we get
the search via a bookmark.
But it doesn't work with the mu4e-headers-search-pre-hook because when I
toggle the setting my settings hook (which matches the search executed
by the bookmark) will just turn it back off again.
Perhaps there's some clever way to know if we're getting to the
mu4e-headers-search-pre-hook via the bookmark that I've missed. But if
there isn't I need a hook that works like this.
14af0d28c8