| Age | Commit message (Collapse) | Author |
|---|
|
The overall goal is to allow clients to restart operations in
situations where that is the response recommended by the underlying
Xapian library.
Amended-by: db, added above explanation
|
|
The list destructor is always set when necessary (i.e. if the iterator
is successfully created), so there is never a need to invoke it
explicitly, even on failure.
|
|
Allow distinguishing between commas separating authors and separating
first and last names.
Amended by db: reformat NEWS entry and commit message. Tweaked
whitespace in lib/thread.cc.
|
|
The function _notmuch_config_load_from_file is only called in two
places in open.cc. Update internal API to match the idiom in open.cc.
Adding a newline is needed for consistency with other status strings.
Based in part on a patch [1] from Eric Blake.
[1]: id:20230906153402.101471-1-eblake@redhat.com
|
|
Higher level processing as a list of regular expressions and
documentation will follow.
|
|
In [1] Austin Ray reported some memory leaks in
notmuch_database_open. One of those leaks is caused by jumping to the
next key without freeing val. This change avoids that leak.
[1]: id:20220105224538.m36lnjn7rf3ieonc@athena
|
|
Used in a following commit to enable including extra headers beyond
the default in structured output.
|
|
If we know the configuration is split, but there is no mail root
defined, this indicates a (lack of) configuration error. Currently
this can only arise in XDG configurations.
|
|
We should not rely on one of the other "_notmuch_config_load_*"
functions being called before this one.
|
|
Unlike the previous g_key_file_get_value, this version processes
escape codes for whitespace and \. The remaining two broken tests from
the last commit are because "notmuch config get" treats every value as
a list, and thus the previously introduces stripping of leading
whitespace applies.
|
|
If the user passed a path, and we opened it, then we consider that
definitive definition of "database.path". This makes libnotmuch
respond more gracefully to certain erroneous combinations of
NOTMUCH_CONFIG settings and config file contents.
|
|
As discussed in the thread starting at [1], the fully qualified domain
name is a bit tricky to get reproducibly, might reveal information
people prefer to keep private, and somewhat unlikely to provide
reliable mail routing.
The new approach of $current_username@localhost is better for the
first two considerations, and probably at least as good as a test mail
address.
[1]: id:87sfyibqhj.fsf@tethera.net
|
|
This will be used to control how often atomic transactions are
committed.
|
|
This commit fixes a small memory leak (per iterator restart) by
actually using the talloc context intended to be blown away on
restart.
|
|
This makes the treatment of relative paths consistent between the
database and config files.
|
|
Prior to 0.32, notmuch had the (undocumented) behaviour that it
expanded a relative value of database.path with respect to $HOME. In
0.32 this was special cased for database.path but broken for
database.mail_root, which causes problems for at least notmuch-new
when database.path is set to a relative path.
The change in T030-config.sh reflects a user visible, but hopefully
harmless behaviour change; the expanded form of the paths will now be
printed by notmuch config.
|
|
This (obvious) bug was caused by cut&pasting the code from
notmuch-config.c into the library and adding on a return at the end.
|
|
Since the library searches in several locations for a config file, the
caller does not know which of these is chosen in the usual case of
passing NULL as a config file. This changes provides an API for the
caller to retrieve the name of the config file chosen. It will be
tested in a following commit.
|
|
notmuch_config_open will be preserved in the medium term for use by
the commands that are manipulating the config file directly (config
and setup)
|
|
This is mainly copying code from the CLI into the lib. The CLI copy
will be deleted in a later commit.
|
|
This just copies code from from the CLI into the library. New test
infrastructure is needed because apparently we have never tested this
code path.
|
|
The layer of shims here seems a bit wasteful compared to just calling
the corresponding string map functions directly, but it allows control
over the API (calling with notmuch_database_t *) and flexibility for
future changes.
|
|
This is to support the less common (at least in the notmuch codebase)
case of accessing a ;-delimited list config value with an arbitrary
string key.
|
|
Like the hook directory, we primarily need a way to communicate this
directory between various components, but we may as well let the user
configure it.
Most of the diff is generalizing choose_hook_dir to work for both
backup and hook directories.
|
|
Introduce a new configuration value for the mail root, and use it to
locate mail messages in preference to the database.path (which
previously implied the mail messages were also in this location.
Initially only a subset of the CLI is tested in a split
configuration. Further changes will be needed for the remainder of the
CLI to work in split configurations.
|
|
This removes duplication between the struct element and the
configuration string_map entry. Create a simple wrapper for setting
the database path that makes sure the trailing / is stripped.
|
|
This fixes a few small memory leaks.
|
|
This is the result of running
$ uncrustify --replace --config ../devel/uncrustify.cfg *.c *.h *.cc
in the lib directory
|
|
The hook directory configuration needs to be kept in synch with the
other configuration information, so add scaffolding to support this at
database opening time.
|
|
This will be needed by (at least) the conversion of notmuch-new.c to
the new config framework
|
|
This is a simple convenience routine to cache a configuration value
without writing it to the database.
|
|
Booleans have no out of band values, so return a status for errors.
|
|
This is relatively cheap, and makes it easier to transform existing
code which uses arrays of pointers to store configuration lists.
|
|
This is intended to avoid duplicating the string splitting and
traversal code for all clients of the config API.
|
|
This emulates the behaviour of notmuch_config_open defined in the CLI,
in that it fills in default values if they are not otherwise defined.
|
|
By using an enum we can have better error detection than copy pasting
key strings around.
The question of what layer this belongs in is a bit
tricky. Historically most of the keys are defined by the CLI. On the
other hand features like excludes are supported in the
library/bindings, and it makes sense to configure them from the
library as well.
The somewhat long prefix for notmuch_config_t is to avoid collisions
with the existing usage in notmuch-client.h.
|
|
Fill in the remainder of the documented functionality for
n_d_open_with_config with respect to config file location. Similar
searching default locations of the database file still needs to be
added.
|
|
Initially document the intended API and copy the code from
notmuch_database_open_verbose. Most of the documented functionality is
not there yet.
|
|
The main goal is to allow configuration information to be temporarily
overridden by a separate config file. That will require further
changes not in this commit.
The performance impact is unclear, and will depend on the balance
between number of queries and number of distinct metadata items read
on the first call to n_d_get_config.
|
|
If Xapian has thrown an exception, it is not safe to invoke the
destructor when freeing the list struct.
|
|
As diagnosed by Olivier Taïbi in
id:20201027100916.emry3k2wujod4xnl@galois.lan, if an exception is
thrown while the initialization is happening (e.g. if the function is
called on a closed database), then the destructor is (sometimes)
invoked on an uninitialized Xapian object.
Solve the problem by moving the setting of the destructor until after
the placement new successfully completes. It is conceivable this might
cause a memory leak, but that seems preferable to crashing, and in any
case, there seems to be nothing better to be done if the
initialization is failing things are in an undefined state by
definition.
|
|
static_cast is a bit tricky to understand and error prone, so add a
second pointer to (potentially the same) Xapian database object that
we know has the right subclass.
|
|
The catch block either needs to return, or the function needs to
return "status". Choose the latter for consistency with
n_d_get_config.
|
|
notmuch release 0.29.3-1 for unstable (sid) [dgit]
[dgit distro=debian no-split --quilt=linear]
|
|
The documentation for notmuch_config_list_key warns that that the
returned value will be destroyed by the next call to
notmuch_config_list_key, but it neglected to mention that calling
notmuch_config_list_value would also destroy it (by calling
notmuch_config_list_key). This is surprising, and caused a use after
free bug in _setup_user_query_fields (first noticed by an OpenBSD
porter, so kudos to the OpenBSD malloc implementation). This change
fixes that use-after-free bug.
|
|
This is the result of running
$ uncrustify --replace --config ../devel/uncrustify.cfg *.c *.h *.cc
in the lib directory
|
|
C99 stdbool turned 18 this year. There really is no reason to use our
own, except in the library interface for backward
compatibility. Convert the lib internally to stdbool.
|
|
Many of the external links found in the notmuch source can be resolved
using https instead of http. This changeset addresses as many as i
could find, without touching the e-mail corpus or expected outputs
found in tests.
|
|
Since xapian provides the ability to restrict the iterator to a given
prefix, we expose this ability to the user. Otherwise we mimic the other
iterator interfances in notmuch (e.g. tags.c).
|
|
This is a thin wrapper around the Xapian metadata API. The job of this
layer is to keep the config key value pairs from colliding with other
metadata by transparently prefixing the keys, along with the usual glue
to provide a C interface.
The split of _get_config into two functions is to allow returning of the
return value with different memory ownership semantics.
|
