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.
We basically steal all the objects from their notmuch parents, therefore
they are completely under Ruby's gc control.
The order at which these objects are freed does not matter any more,
because destroying the database does not destroy all the children
objects, since they belong to Ruby now.
Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com>
Currently Ruby data points directly to a notmuch object (e.g.
notmuch_database_t), since we don't need any extra data that is fine.
However, in the next commit we will need extra data, therefore we create
a new struct notmuch_rb_object_t wrapper which contains nothing but a
pointer to the current pointer (e.g. notmuch_database_t).
This struct is tied to the Ruby object, and is freed when the Ruby
object is freed by the garbage collector.
We do nothing with this wrapper, so no functionality should be changed.
Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com>
Simply list the message-id of all the messages in a loop 100 times.
Suggested-by: David Bremner <david@tethera.net>
Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com>
New --sort CLI option documented in notmuch-show's man page, and
notmuch-search-toggle-order mentioned in doc/notmuch-emacs.rst and
devel/emacs-keybindings.org (in the latter, there's also some
whitespace changes in a table introduced by org-mode).
Add the command-line option --sort to the show command of the CLI
notmuch interface, with the same possible values as the same option in
notmuch search.
Test numbers are a concise way to communicate about tests and to remeber
them. Currently, there is one pait of duplicates:
T590-libconfig.sh
T590-thread-breakage.sh
Renumber the latter one to 592 since this keeps the alphabetic order and
leaves room in between.
Signed-off-by: Michael J Gruber <git@grubix.eu>
This is more efficient than notmuch-show-only-matching-messages, since
we do not parse the potentially large thread structure to find a
single message.
This is only a partial fix for notmuch-tree view, because displaying
the thread structure in the tree-mode window still crashes on long
threads. It is however enough to make unthreaded view handle long
threads.
This dynamically bound variable can be set when the caller of
notmuch-show guarantees that exactly one message will match the
query. It avoids transporting and parsing the complete thread
structure.
All three of C-c C-c, <menu-bar> <Message> <Send Message>,
and <tool-bar> <Send Message> are bound to message-send-and-exit by
message.el, but notmuch-mua.el only had an explicit override for the
keyboard binding. This mostly manifests as confusing Fcc behaviour for
GUI users.
Patching the bindings for specific keys is rather brittle, since it has
to be aware of every relevant binding. This change switches to instead
using a remap binding, which turns any binding for message-send or
message-send-and-exit into a binding for the corresponding notmuch-mua
command.
This change addresses two known issues with large sets of changes to
the database. The first is that as reported by Steven Allen [1],
notmuch commits are not "flushed" when they complete, which means that
if there is an open transaction when the database closes (or e.g. the
program crashes) then all changes since the last commit will be
discarded (nothing is irrecoverably lost for "notmuch new", as the
indexing process just restarts next time it is run). This does not
really "fix" the issue reported in [1]; that seems rather difficult
given how transactions work in Xapian. On the other hand, with the
default settings, this should mean one only loses less than a minutes
worth of work. The second issue is the occasionally reported "storm"
of disk writes when notmuch finishes. I don't yet have a test for
this, but I think committing as we go should reduce the amount of work
when finalizing the database.
[1]: id:20151025210215.GA3754@stebalien.com
Unfortunately, it doesn't make a difference if we call
cancel_transaction or not, all uncommited changes are discarded if
there is an open (unflushed) transaction.
The minibuffer-prompt face that was used before made it impossible to
differentiate between two distinct UI elements: (i) the prompt's text
which itself cannot be acted upon, (ii) the actionable keys used to
jump to searches/tags.
The use of a named face, notmuch-jump-key, makes it possible for users
or theme developers to apply properties that are specific to each of
those two cases.
In the interest of backward compatibility, the new face inherits from
minibuffer-prompt.
This prevents the message document getting multiple thread-id terms
when there are multiple files with the same message-id.
This change shifts some thread ids, requiring adjustments to other tests.
(cherry picked from commit 3f4de98e7c)
Most concrete verification steps are likely only taken on the e-mail
address in the first place, and e-mail addresses render more
intelligibly than arbitrary User IDs in the first place.
Signed-off-by: Daniel Kahn Gillmor <dkg@fifthhorseman.net>
Amended-by: db, apply dme restructuring suggestions.
When the certificate that signs a message is known to be valid, GMime
is capable of reporting on the e-mail address embedded in the
certificate.
We pass this information along to the caller of "notmuch show", as
often only the e-mail address of the certificate has actually been
checked/verified.
Furthermore, signature verification should probably at some point
compare the e-mail address of the caller against the sender address of
the message itself. Having to parse what gmime thinks is a "userid"
to extract an e-mail address seems clunky and unnecessary if gmime
already thinks it knows what the e-mail address is.
See id:878s41ax6t.fsf@fifthhorseman.net for more motivation and discussion.
Signed-off-by: Daniel Kahn Gillmor <dkg@fifthhorseman.net>
