It seems redundant to have the previous example, since the default
value is always show by describe variable.
Enforce more restrictions on the keys in the alist, since arbitrary
strings don't work as field names.
Document that functions can be used in lieu of field names.
It seems redundant to have the previous example, since the default
value is always show by describe variable.
Enforce more restrictions on the keys in the alist, since arbitrary
strings don't work as field names.
Document that functions can be used in lieu of field names.
Essentially we just need to arrange to pass the right --duplicate
argument to notmuch reply.
As a side-effect, correct the previously unused value of EXPECTED in
T453-emacs-reply.sh.
We want the reply used to match that shown e.g. in the emacs
interface. As a first step provide that functionality on the command
line.
Schema does not need updating as the duplicate key was already
present (with a constant value of 1).
This new command allows the user to interactively choose a different
duplicate (file) to display for a given message in
notmuch-show-mode. Since both tree and unthreaded view use
notmuch-show-mode, this provides the same facility there.
This introduces a new mandatory key for message structures, namely
"duplicate". Per convention in devel/schemata this does _not_ increase
the format version. This means that clients are responsible for
checking that it exists, and not crashing if it does not.
The main functional change is teaching mime_node_open to understand a
'duplicate' argument.
Support for --duplicate in notmuch-reply would make sense, but we
defer it to a later commit.
Add command line argument --duplicate, analogous with that already
supported for notmuch-search.
Use of a seperate function for _get_filename is mainly a form of
documentation at this point.
md5sum is of course a weak hash, but it is good enough for
this (non-adversarial) test suite use.
Rather than shelling out once per message to get the list of files
corresponding to tags, it is much faster (although potentially a bit
memory intensive) to read them all at once.
Answering a user question, I had to dig for this variable, but I think
it is a reasonably common customization wish, particularly for users
with custom count-functions.
This mainly affects the html output (although users generating epub or
pdf would also notice a change). The goal is twofold: make the TOC a
bit friendler and easier to navigate by introducing some hierarchy,
and allow links for nmbug and notmuch-setup.
Commit 306b7028d added the nmconfig role / directive. Unfortunately
the default of using the directive name in texinfo output is pretty
ugly, so attempt to make it more human readable by passing `objname`
to add_object_type invocation.
This parameter was originally introduced to hide large attachements
that happened to be text/plain. From a performance point of view,
there is no reason not to also hide large message bodies.
This leverages the machinery already there to insert buttons for
attachments.
A potential use-case is browsing the top layers of the tree to decide
which of the lower subtrees to read.
This particular thread takes about 100 times longer to display in
emacs than on the command line.
The parameter notmuch-show-max-text-part-size exists, but is currently
ineffective for this task because it only hides attachments, not
part 0.
In future commits, the parameter notmuch-show-{depth,height}-limit
will trigger a similar kind of hiding for bodies as
n-s-m-text-part-size already does for attachments.
The original nmbug format (now called version 0) creates 1
subdirectory of 'tags/' per message. This causes problems for more
than (roughly) 100k messages.
Version 1 introduces 2 layers of hashed directories. This scheme was
chose to balance the number of subdirectories with the number of extra
directories (and git objects) created via hashing.
This should be upward compatible in the sense that old repositories
will continue to work with the updated notmuch-git.
In split configurations there is no special significance to a top
level directory called .notmuch in the mail root. Users should
therefore be able to have mail stored underneath it.
This makes the tests more robust against changing output formats, by
allowing us to centralize fixes in the sanitization function. It is
not appropriate for all cases, in particular it is unneeded when using
test_json_nodes, and unhelpful when testing filenames.
Previously only man page aliases were being added as symlinks. The
addition to man_pages in conf.py automatically propagates to the list
of generated info pages.
Installation of the new pages is handled by existing recipes.
The only functionality actually used by notmuch is the base function
notmuch-query-get-threads; the other functions in this file have
nothing to do with that (single) use. Move that function into
notmuch-lib.el and rename to reflect use. Deprecate the other
functions in notmuch-query.el.
Fix the bug reported at [1].
The parameter expansion for regex and wildcard modifiers has to be
done a bit differently, because their arguments are not s-expressions
defining complete Xapian queries.
[1]: id:87o7yxqxy6.fsf@code.pm
The date range parsing machinery already knows how to do something
appropriate with an empty string, but the lastmod parsing blindly
tries to parse each atom as a number.
In order for a database to actually be writeable, it must be the case that it
is open, not just the correct type of Xapian object. By explicitely
checking, we are able to provide better error reporting, in particular
for the previously broken test in T566-lib-message.
Make the behaviour when passed NULL consistent with
notmuch_filenames_valid. The library already passes the result of
notmuch_message_get_tags without checking for NULL, so it should be
handled.
This should return false, but currently segfaults.
Start a new file for tags library API related tests. This is maybe
overkill, but new C boilerplate which doesn't corrupt the database is
needed anyway.
