The retries are hardcoded to a small number, and error handling aborts
than propagating errors from notmuch_database_reopen. These are both
somewhat justified by the assumption that most things that can go
wrong in Xapian::Database::reopen are rare and fatal. Here's the brief
discussion with Xapian upstream:
24-02-2017 08:12:57 < bremner> any intuition about how likely
Xapian::Database::reopen is to fail? I'm catching a
DatabaseModifiedError somewhere where handling any further errors is
tricky, and wondering about treating a failed reopen as as "the
impossible happened, stopping"
24-02-2017 16:22:34 < olly> bremner: there should not be much scope for
failure - stuff like out of memory or disk errors, which are probably a
good enough excuse to stop
$NOTMUCH_PYTHON is sourced from sh.config, configured by
./configure and stated to be used as:
"Name of python command to use in configure and the test suite."
We now have several customizable options for address completion. There
is a customize group notmuch-address but it only contains one of these
options. Add all the others, and make it part of the notmuch customize
group.
The two g_hash_table functions (insert, add) have different behaviour
with respect to existing keys. g_hash_table_insert frees the new key,
while g_hash_table_add (which is really g_hash_table_replace in
disguise) frees the existing key. With this change 'ref' is live until
the end of the function (assuming single-threaded access to
'hash'). We can't guarantee it will continue to be live in the
future (i.e. there may be a future key duplication) so we copy it with
the allocation context passed to parse_references (in practice this is
the notmuch_message_t object whose parents we are finding).
Thanks to Tomi for the simpler approach to the problem based on
reading the fine glib manual.
This enables the shortened socket pathes in /run or equivalent. The
explicit call to gpgconf is needed for nonstandard GNUPGHOME settings.
(amended according to id:m2fujatr4k.fsf@guru.guru-group.fi)
This is primarily intended for use in the test suite (since notmuch
builds fine without gnupg installed). Thus we only write the variable
to sh.config.
Replace multiple tables with some flags in a single table. This makes
the code in notmuch_database_open_verbose a bit shorter, and it should
also make it easier to add other options to fields, e.g. regexp
searching.
This allows the user to save the address hash so that it is much
faster for the first completion after a restart. This defaults to off
as there are privacy implications to saving this information.
The code tries hard to avoid overwriting the wrong file. It also notes
if changes have been made to any of the relevant user settings, so
that the user does not get surprising results (i.e., outdated options
being used). Finally it stores some version information so that is
easy for us to update the format of the save file.
This makes the code access notmuch-address-full-harvest-finished via a
helper function, notmuch-address--harvest-ready. Later we will use
this to check whether we can load the harvest instead of regenerating
it.
Split file ignores in count_files to fixed and user configured in
order to not have to call _entry_in_ignore_list twice when debugging
is enabled. Minor detail.
From #xapian
olly> bremner: btw, i noticed notmuch count see ms to request all the documents and then ignores them
bremner> hmm. There's something funny about the way that notmuch uses matches in general iirc
olly> it should be able to do: mset = enquire.get_mset (0, 0, notmuch->xapian_db->get_doccount ());
...
olly> get_matches_estimated() will be exact because check_at_least is the size of the database
Removing the removal of byteorder configure test files was overlooked
in commit 5a957c3f33 ("build & util: drop byte order configure check
and endian util header"). Finish the job.
With the removal of the embedded libsha1, we lost the first and last
user of the platform byte order checks. Remove them from configure,
and remove the endian util header.
We already depend on glib both directly and indirectly (via gmime). We
might as well make use of its facilities. Drop the embedded libsha1
and use glib for sha1 digests.
The todo comment got separated from the status it's related to at
commit 3f32fd8a1c ("Add missing comment for
NOTMUCH_STATUS_READONLY_DATABASE."). Later, commit b65ca8e0ba ("lib:
modify notmuch.h for automatic document generation") moved it, but to
the wrong place. Fix the location.
Do not initialize each field separately. It's more robust to allocate
the config with zero initialization, and only set the non-zero
defaults individually.
Since the sed expansion line which did $prefix expansion for
libdir_expanded was changed from the legacy `...` format to the
new $(...) expression, the subtle backslash expansion change went
unnoticed -- \\$ which used to escape '$' now escapes '\' and the
following '$prefix' was attempted to expand as a variable. So
changing \\$ to \$ fixes this.
Also, replaced echo with printf %s -- echo does expansions of its own.
While at it, the following 2 inconsistencies were fixed:
1) the /g flag was removed from first expression; second didn't have it
2) first expression did not end with /, so "dropped" it from second
configure | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
Config files are currently read using glib's g_key_file_load_from_file
function which is very inconvenient because it's limited by design to read
only from "regular data files" in a filesystem. Because of this limitation
notmuch can't read configs from pipes, fifos, sockets, stdin, etc. Not even
"notmuch --config=/dev/stdin" works:
Error reading configuration file /dev/stdin: Not a regular file
So replace g_key_file_load_from_file with g_key_file_load_from_data which
gives us much more freedom to read configs from multiple sources.
This also helps the more security sensitive users: If someone has private
information in the config file, it can be encrypted on disk, then decrypted
in RAM and passed through a pipe directly to notmuch without the use of
intermediate plain text files.
Signed-off-by: Ioan-Adrian Ratiu <adi@adirat.com>
