Formerly the documentation was overly verbose. Reword the comment and
use the same for both functions.
Signed-off-by: Justus Winter <4winter@informatik.uni-hamburg.de>
Remove the function Filenames.as_generator that has been marked as
deprecated in 0.12.
The class Filenames implements the iterator protocol so you can
directly iterate over such objects instead.
Signed-off-by: Justus Winter <4winter@informatik.uni-hamburg.de>
The main change here is to modify argument parsing so as to not force
tag-changes to be a list, and to let notmuch-tag handle prompting the
user when required. doc strings are also updated and cleaned up.
The main change here is to modify argument parsing so as to not force
tag-changes to be a list, and to let notmuch-tag handle prompting the
user when required. doc strings are also updated and cleaned up.
notmuch-tag is extended to accept various formats of the tag changes.
In particular, user prompting for tag changes is now incorporated
here, so it is common for modes.
The tag binary and the notmuch-{before,after}-tag-hooks are only
called if tag changes is non-nil.
In all cases tag-changes is returned as a list.
Tagging functions are used in notmuch.el, notmuch-show.el, and
notmuch-message.el. There are enough common functions for tagging
that it makes sense to put them all in their own library.
No code is modified, just moved around.
When using the spacebar to scroll through a thread, hitting 'space'
when the bottom of the last message is visible should take the cursor
to the end of the buffer rather than immediately archiving the thread
and moving to the next thread.
Currently emacs show does not open matching but excluded
messages. This is normally the desired behaviour but is probably not
ideal if only excluded messages match. This patch opens all the
matching (necessarily excluded) messages in this case and goes to the
first one.
A previous patch [0] replaced blank subject lines with '[No Subject]'
in search and show mode. Apparently this was needed to circumvent
some bug in the printing code, but there was no need for it search or
show, and it is definitely not desirable, so we undo it here (a revert
is no longer feasible). We should not be modifying strings in the
original message without good reason, or without a clear indication
that we are doing so, neither of which apply in this case. For
further discussion see [0].
[0] id:"1327918561-16245-3-git-send-email-dme@dme.org"
Add a command to list all configuration items with their associated
values.
One use is as follows: a MUA may prefer to store data in a central
notmuch configuration file so that the data is accessible across
different machines, e.g. an addressbook. The list command helps
to implement features such as tab completion on the keys.
Require that 'config get' is passed exactly one additional argument,
instead of silently ignoring extra arguments. As a side-effect, produce
more specific error messages for the 'config' command as a whole.
Formerly notmuch_database_close closed the xapian database and
destroyed the talloc structure associated with the notmuch database
object. Split notmuch_database_close into notmuch_database_close and
notmuch_database_destroy.
This makes it possible for long running programs to close the xapian
database and thus release the lock associated with it without
destroying the data structures obtained from it.
This also makes the api more consistent since every other data
structure has a destructor function.
The comments in notmuch.h are a courtesy of Austin Clements.
Signed-off-by: Justus Winter <4winter@informatik.uni-hamburg.de>
Previously, if we failed to find the message by filename in
remove_filename, we would return immediately from the function without
ending its atomic block. Now this code follows the usual goto DONE
idiom to perform cleanup.
This was going to stdout. I removed the newline at the beginning of
printing the fatal error message because it wouldn't make sense if you
were only looking at the stderr stream (e.g., you had redirected
stdout to /dev/null).
Previously, fatal errors in add_files_recursive were not treated as
fatal by its callers (including itself!). This makes
add_files_recursive errors consistently fatal and updates all callers
to treat them as fatal.
No functional change here. The help message previously referred to
the "delete" tag, but "deleted" is now preferred, so hopefully this
will reduce any potential confusion.
There should be no functional changes, except that you don't need to
make the directories before installing.
Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com>
Implicit typecast from 'void *' to 'T *' is okay in C, but not in
C++. In talloc_steal, an explicit cast is provided for type safety in
some GCC versions. Otherwise, a cast is required. Provide a template
function for this to maintain type safety, and redefine talloc_steal
to use it.
The template must be outside the extern "C" block (NOTMUCH_BEGIN_DECLS
and NOTMUCH_END_DECLS), but keep it within the GCC visibility #pragma.
No functional changes, apart from making the library build with
compilers other than recent GCC.
Signed-off-by: Jani Nikula <jani@nikula.org>
Previously, the makefile created dependency files in a separate, first
pass. In particular, include-ing the dependency files would cause
make to attempt to rebuild those files using the dependency-generation
rules in the makefile. Unfortunately, this approach required obtuse
rules and silently delayed the start of the build process (by quite a
bit on a clean tree without any dependency files). Worse, this
required the dependency files to themselves depend on all of the
headers the source file depended on, which meant that, if a header
file was removed, the depedency file could not be updated because of a
missing dependency (!), which would cause make to silently fail.
This patch eliminates the dependency generation rules and instead
generates dependency files as a side-effect of the regular build rule.
On the first build, we don't need to know the dependencies beforehand;
the object file doesn't exist, so it will be built anyway. On
subsequent builds, if a header file is updated, the dependency rules
generated by the previous build will force a rebuild. If a source
file is updated, the dependency rules may be stale, but it doesn't
matter because the updated source file will force a rebuild.
In the final case above, the stale dependency rules may refer to a
header file that no longer exists but is also no longer needed. In
order to prevent this from breaking the build, we also pass gcc the
-MP option, which generates phony targets for every depended-on header
file, so make won't complain if it can't find them during a later
build.
