This avoids some ugly error messages and exceptions, and hopes that
some gnus method will display message/rfc822 parts that have only a
file, no :content part.
There are at least 3 bugs present.
1) notmuch-show-insert-part-message/rfc822 assumes that message/rfc822
parts will have a ":content" property, but that turns out not to be
the case.
2) something deep in gnus wants gnus-newsgroup-charset, but that is
defined in gnus-sum, which is not loaded by default.
3) If gnus-sum is loaded, then the display of the message/rfc822 part
succeeds, but the buffer gets put into gnus-article-mode, which means
that, inter alia, notmuch text properties and keybindings get wiped.
When using notmuch-reply and guessing the From: address from
Delivered-To headers, I had the wrong address chosen today. This was
because the messages from the notmuch list contain these headers in this
order:
Delivered-To: hannu.hartikainen@gmail.com
...
Delivered-To: hannu@hrtk.in
In my .notmuch-config I have the following configuration:
primary_email=hannu@hrtk.inother_email=hannu.hartikainen@gmail.com;...
Before this change, notmuch-reply would guess From: @gmail.com because
that is the first Delivered-To header present. After the change, the
primary address is chosen as I would expect.
Add a known broken subtest for guessing From: correctly when there are
multiple Delivered-To: headers. The address configured as primary_email
should get picked.
This is just a regular character in docstrings (as it is fairly often
used in lisp identifiers and buffer names) but is the start of
emphasis in rst. This change is needed to quell a noisy warning when
including notmuch-tree.rsti
This is a bit of a cheat, since the format does not actually
change. On the other hand it is fairly common to do something like
this to shared libary SONAMEs when the ABI changes in some subtle way.
It does rely on the format-version argument being early enough on the
command line to generate a sensible error message.
This new command for notmuch-tree-mode is analogous to
notmuch-search-filter-by-tag, bound to "t" in notmuch-search-mode; it
gets therefore the same "t" keybinding in notmuch-tree-mode (replacing
the current assignment to notmuch-search-by-tag).
This is more robust against crashes when the expected output is also
generated by notmuch. In the case where the expected output is
explicit, it seems like overkill.
A common bug in tests is that the code used to generate the EXPECTED
file fails, generating no output. When the code generating the OUTPUT
file fails in the same way, the test passes, even though there is a
failure being hidden. Add a new test function that guards against
this.
We need to special case the config section "built_with" because it is
not (currently) handled by the library. This seems consist with the
other sub-sub-commands 'list' and 'set'.
This highlights a bug reported by several users, including
Mohsin Kaleem [1].
The inconsistent use of test_begin_subtest_known_broken is because
some of these tests pass even though the database cannot be
located. This problem is left for a future commit.
[1]: id:87bl9lx864.fsf@kisara.moe
Notmuch 0.32 corresponds to libnotmuch 5.4 as indicated by docstrings;
however, the minor number wasn't bumped. Any libnotmuch downstream
consumer using the LIBNOTMUCH_CHECK_VERSION macro to support multiple
versions won't be able to access the new 5.4 functions.
Signed-off-by: Austin Ray <austin@austinray.io>
Both notmuch_database_open() and notmuch_database_open_verbose()'s
documentation state they call notmuch_database_open_with_config() with
config_path=NULL; however, their implementations pass an empty string.
The empty string is the correct value to maintain their original
behavior of not loading the user's configuration so their documentation
is incorrect.
The intent of the 'notmuch-jump-key' face is to allow users/themes to
differentiate the text of the minibuffer prompt from the keys that are
associated with jump actions. Commit 5cc106b0 correctly introduced the
'notmuch-jump-key' face for keys, but mistakenly applied it to the
prompt as well.
When mm-text-html-renderer is set to 'w3m, the variable playing the
role of a regular expression for blocked images is
w3m-ignored-image-url-regexp. We bind it when the renderer is not
'shr.
It was assumed the destructor of notmuch_rb_database_type did return a
notmuch_status_t because that's what notmuch_database_close returns, and
that value was checked by notmuch_rb_database_close in order to decide
if to raise an exception.
It turns out notmuch_database_destroy was called instead, so nothing was
returned (void).
All the destroy functions are void, and that's what we want.
Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com>
BSD xargs does not have the -d option. Here we use tr to convert
newlines to NUL characters, then pass -0 to xargs (which BSD does
support).
I looked at passing -z to 'git ls-files', but I did not find a BSD
grep option to turn on NUL deliminted line processing.
Mathias Beyer [1] points out that this note is redudant since Xapian
no longer builds with the problematic versions of Xapian.
[1]: id:20210207124404.yldgtzjrsagacrl4@hoshi
Mirrors the C API: 7864350c (Split notmuch_database_close into two
functions, 2012-04-25).
Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com>
When moving between message in a tree or show buffer, the message at
point is marked as read. Likewise when creating such a buffer, then
the message that is initially at point is supposed to be marked as
read as well.
The latter worked for `notmuch-show' but not for `notmuch-tree'.
Press "RET" or "M-RET" in a search buffer to observe these behaviors.
In both cases the marking is supposed to be done by the function
`notmuch-show-command-hook'. In the case of `notmuch-show' that
function is added directly to `post-command-hook'.
`notmuch-tree' instead adds the function `notmuch-tree-command-hook'
to `post-command-hook' and that calls `notmuch-show-command-hook',
in the respective show buffer, but of course only if that exists.
Because the tree buffer is created asynchronously, the show buffer
doesn't exist yet by the time the `post-command-hook' is run, so
we have to explicitly run `notmuch-tree-command-hook' once the
show buffer exists.
The show buffer is created when `notmuch-tree-goto-and-insert-msg'
calls `notmuch-tree-show-message-in'. `notmuch-tree-process-filter'
is what finally brings us here.
