Michal Sojka writes:
> Notmuch currently has an address completion mechanism that requires
> external script to provide completion candidates. This patch adds a
> completion mechanism found in https://github.com/tjim/nevermore, which
> is implemented in elisp only.
I was playing with this a bit
Notmuch currently has an address completion mechanism that requires
external script to provide completion candidates. This patch adds a
completion mechanism found in https://github.com/tjim/nevermore, which
is implemented in elisp only.
notmuch-lib.el is extended with function
Hi all!
On Wed, Jul 16 2014, Trevor Jim wrote:
> If you would like to incorporate things into the main branch, that
> would be great. Here's what I think the status is:
>
> The asynchronous mail address harvesting works pretty well. Much
> better than having to install python etc. It would be
Clients are no longer required to call these functions after opening a
database in read/write mode (which is good, because almost none of
them do!).
---
lib/notmuch.h | 21 -
1 file changed, 12 insertions(+), 9 deletions(-)
diff --git a/lib/notmuch.h b/lib/notmuch.h
index
Previously, there was no protection against a caller invoking an
operation on an old database version that would effectively corrupt
the database by treating it like a newer version.
According to notmuch.h, any caller that opens the database in
read/write mode is supposed to check if the database
Commit 567bcbc2 introduced support for storing various headers in
document values. However, doing so in a backwards-compatible way
meant that genuinely empty header values could not be distinguished
from the old behavior of not storing the headers at all, so these
required parsing the original
Previously, some parts of upgrade didn't report progress and for
others it was possible for the progress meter to restart at 0 part way
through the upgrade because each stage was reported separately.
Fix this by computing the total amount of work that needs to be done
up-front and updating
Rather than potentially making multiple passes over the same type of
data in the database, reorganize upgrade around each type of data that
may be upgraded. This eliminates code duplication, will make
multi-version upgrades faster, and will let us improve progress
reporting.
---
lib/database.cc
Previously, we had database version information hard-coded in the
upgrade code. Slightly re-organize the upgrade process around the set
of new database features to be enabled by the upgrade.
---
lib/database.cc | 24 +---
1 file changed, 13 insertions(+), 11 deletions(-)
Previously, the upgrade was organized as two passes -- an upgrade
pass, and a separate cleanup pass -- so the database was always in a
valid state. This change substantially simplifies this code by
performing the upgrade in a transaction and combining both passes in
to one. This 1) eliminates a
---
test/T550-db-features.sh | 48
1 file changed, 48 insertions(+)
create mode 100755 test/T550-db-features.sh
diff --git a/test/T550-db-features.sh b/test/T550-db-features.sh
new file mode 100755
index 000..5569768
--- /dev/null
+++
This will let us test basic version and feature handling.
---
test/.gitignore | 1 +
test/Makefile.local | 4
test/make-db-version.cc | 35 +++
3 files changed, 40 insertions(+)
create mode 100644 test/make-db-version.cc
diff --git
Previously, our database schema was versioned by a single number.
Each database schema change had to occur "atomically" in Notmuch's
development history: before some commit, Notmuch used version N, after
that commit, it used version N+1. Hence, each new schema version
could introduce only one
The version number has always been pretty meaningless to the user and
it's about to become even more meaningless with the introduction of
"features". Hopefully, the database will remain on version 3 for some
time to come; however, the introduction of new features over time in
version 3 will
Because of limitations in the C type system, we can't a strtok_len
that can work on both const string and non-const strings. The C
library solves this by taking a const char* and returning a char*
in functions like this (e.g., strchr), but that's not const-safe.
Solve it by introducing
---
util/string-util.h | 8
1 file changed, 8 insertions(+)
diff --git a/util/string-util.h b/util/string-util.h
index 8a3ad19..ccad17f 100644
--- a/util/string-util.h
+++ b/util/string-util.h
@@ -3,6 +3,10 @@
#include
+#ifdef __cplusplus
+extern "C" {
+#endif
+
/* like strtok(3),
This is version 2 of
id:1406433173-19169-1-git-send-email-amdragon at mit.edu. It fixes a bug
pointed out by Mark [1] where the upgrade test would fail if the
prerequisites were not available (rather than cleanly skipping the
test like before). It also makes feature names more user-friendly and
On Wed, 09 Jul 2014 20:20:17 -0300, David Bremner wrote:
> Peter Wang writes:
>
> > This option causes notmuch insert to fail (with exit code 3) on failure
> > to index the message, or failure to set the tags on the message, or if
> > closing (flushing) the database fails. Failure to sync tags
Previously the build system was generating automatic header
dependencies for test sources, but only smtp-dummy was in SRCS, so
only its dependencies were being included. Add all of the test
sources to SRCS so that the root Makefile.local includes their
dependencies.
---
test/Makefile.local | 19
---
test/T550-db-features.sh | 48
1 file changed, 48 insertions(+)
create mode 100755 test/T550-db-features.sh
diff --git a/test/T550-db-features.sh b/test/T550-db-features.sh
new file mode 100755
index 000..5569768
--- /dev/null
+++
Previously, our database schema was versioned by a single number.
Each database schema change had to occur atomically in Notmuch's
development history: before some commit, Notmuch used version N, after
that commit, it used version N+1. Hence, each new schema version
could introduce only one
Commit 567bcbc2 introduced support for storing various headers in
document values. However, doing so in a backwards-compatible way
meant that genuinely empty header values could not be distinguished
from the old behavior of not storing the headers at all, so these
required parsing the original
This is version 2 of
id:1406433173-19169-1-git-send-email-amdra...@mit.edu. It fixes a bug
pointed out by Mark [1] where the upgrade test would fail if the
prerequisites were not available (rather than cleanly skipping the
test like before). It also makes feature names more user-friendly and
---
util/string-util.h | 8
1 file changed, 8 insertions(+)
diff --git a/util/string-util.h b/util/string-util.h
index 8a3ad19..ccad17f 100644
--- a/util/string-util.h
+++ b/util/string-util.h
@@ -3,6 +3,10 @@
#include string.h
+#ifdef __cplusplus
+extern C {
+#endif
+
/* like
Clients are no longer required to call these functions after opening a
database in read/write mode (which is good, because almost none of
them do!).
---
lib/notmuch.h | 21 -
1 file changed, 12 insertions(+), 9 deletions(-)
diff --git a/lib/notmuch.h b/lib/notmuch.h
index
Previously, there was no protection against a caller invoking an
operation on an old database version that would effectively corrupt
the database by treating it like a newer version.
According to notmuch.h, any caller that opens the database in
read/write mode is supposed to check if the database
Because of limitations in the C type system, we can't a strtok_len
that can work on both const string and non-const strings. The C
library solves this by taking a const char* and returning a char*
in functions like this (e.g., strchr), but that's not const-safe.
Solve it by introducing
The version number has always been pretty meaningless to the user and
it's about to become even more meaningless with the introduction of
features. Hopefully, the database will remain on version 3 for some
time to come; however, the introduction of new features over time in
version 3 will
Rather than potentially making multiple passes over the same type of
data in the database, reorganize upgrade around each type of data that
may be upgraded. This eliminates code duplication, will make
multi-version upgrades faster, and will let us improve progress
reporting.
---
lib/database.cc
Previously, the upgrade was organized as two passes -- an upgrade
pass, and a separate cleanup pass -- so the database was always in a
valid state. This change substantially simplifies this code by
performing the upgrade in a transaction and combining both passes in
to one. This 1) eliminates a
Previously, some parts of upgrade didn't report progress and for
others it was possible for the progress meter to restart at 0 part way
through the upgrade because each stage was reported separately.
Fix this by computing the total amount of work that needs to be done
up-front and updating
Previously, we had database version information hard-coded in the
upgrade code. Slightly re-organize the upgrade process around the set
of new database features to be enabled by the upgrade.
---
lib/database.cc | 24 +---
1 file changed, 13 insertions(+), 11 deletions(-)
Hi all!
On Wed, Jul 16 2014, Trevor Jim wrote:
If you would like to incorporate things into the main branch, that
would be great. Here's what I think the status is:
The asynchronous mail address harvesting works pretty well. Much
better than having to install python etc. It would be better
Notmuch currently has an address completion mechanism that requires
external script to provide completion candidates. This patch adds a
completion mechanism found in https://github.com/tjim/nevermore, which
is implemented in elisp only.
notmuch-lib.el is extended with function
34 matches
Mail list logo
