Some message can have an _empty_ message-id, e.g. with:
In-Reply-To: <>
which we weren't filter out.
This would yield and _empty_ Thread-Id, in mu-message.cc
And this would make mu-query believe it had no matches in the first
query, in Query::Private::run_related, and effectively throw away the
results. (Xapian using empty string both for a "not found" result, and
"found an empty string doesn't help either).
So, avoid having an empty reference. Also add a unit-test.
Fixes#2812.
When you ask for bookmarks or maildirs through mu4e-ask-bookmark,
mu4e-ask-maildir, the counts are displayed in the (default) completions
next to the maildirs. This is a shorter version of the full display,
just showing either the delta or the number of unread messages, if any.
If you don't want to see these counts, there is mu4e-hide-short-counts.
Start mu4e if not already; with the transient menus it's easier possible
to try to do things with mu4e before it is started, so handle that
automatically.
Add a first version of a "transient" menu for mu4e. It's just a starting
point. It's not yet bound to any key, but you could e.g. add
(require 'mu4e-transient)
(global-set-key (kbd "C-c m") #'mu4e-transient-menu)
Basically, make the "mu find .... --analyze" information available in
mu4e, through a function mu4e-server-last-query.
This is shows the query as the server saw it, as well as the parse
s-expressions. This can be useful to see how some query is interpreted.
Somewhere along the way, the body-txt and body-html fields were merged
into a single body field. Later, commit 8eac392221 ("guile: re-enable
the guile support") finally removed support for Field::Id::BodyHtml from
mu:c:get-field.
Unfortunately mu.scm and the documentation are still stuck in the past, so
update them. mu:body-txt is now a synonym for mu:body, and mu:body-html
always returns #f.
I wanted to add a mu:body test also for the rfc822.1 message, but there's
currently a bug where its body text is is duplicated (issue #2802), so the
test would fail.
It's stated to be US-ASCII with 7-bit encoding, but it contains the
UTF-8 character '—'.
Fixing the encoding very slightly changes the average size of messages
reported by mu:average, so adjust the new expected value.
