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.
Add `mu4e-compose-resend` to the menus in the headers and view
modes. Don't add a shortcut, as it's a fairly rarely needed feature, and
might be confusing if invoked accidentally.
I'm using this for a rather nasty hack. When I open different bookmarks
in the mu4e-main view I want to set options for them, currently just
tweaking:
* mu4e-headers-show-threads
* mu4e-headers-include-related
* mu4e-headers-skip-duplicates
* mu4e-headers-results-limit
This is because some of my searches are *really* expensive when I
include related threads (huge batches of cron-generated E-Mails), but
some aren't. I couldn't find another way to do this. Using
mu4e-headers-mode-hook doesn't work, because we don't have access to the
search (just a variable showing the last search).
Also maybe we should be passing the actual key chord for the bookmark
here. I don't care since I look up the search string that'll be executed
and go from there, but maybe that interface would make more sense.
But whatever, this works for me, and solves a real use-case.
Because this was a lambda C-h m would just show "??" instead of the
function name, and the documentation would be really confusing since it
showed the deparsed lambda function instead of the function name being
called.
Fix this by refactoring both the view & headers [ and ] functions into
named functions, and make their shared logic new internal
mu4u~{headers,view}-* functions.
with :thread-subject field, we attempt to only show one subject per
thread, somewhat like mutt does it.
the current implementation is straightforward, but does not take into
account whether the thread-subject is currently visible on the screen,
which is a bit tricky to implement
In the headers-view, allow for movig to next and previous
unread/untrashed messages using tab/backtab.
Built on top of the convenience function mu4e-headers-find-if-next.
Update docstrings.
