Previously, we invalidated stored message metadata in
_notmuch_message_add_term and _notmuch_message_remove_term, but not in
_notmuch_message_gen_terms. This doesn't currently result in any bugs
because of our limited uses of _notmuch_message_gen_terms, but it may
could cause trouble in the
The database schema documentation made it sound like each mail
document had exactly one on-disk message file, which hasn't been true
for a long time.
---
lib/database.cc | 9 ++---
1 file changed, 6 insertions(+), 3 deletions(-)
diff --git a/lib/database.cc b/lib/database.cc
index
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
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
This is v3 of id:1406652492-27803-1-git-send-email-amdragon at mit.edu.
This fixes one issue and tidies up another thing in
notmuch_database_upgrade I found while working on change tracking
support. Most of the patches are logically identical to v2, but the
changes ripple through the patch
Michal Sojka writes:
> notmuch-company.el hooks itself into message-mode and uses
> company-mode to offer the completion to the user. The file is put into
> the contrib directory which means that the use has to install it
> himself. This is because company-mode is not a part of Emacs and
>
Hello Everyone.
If this is not the place to address this issue, could you please
direct me to the proper forum.
Info: Using Emacs 24.3.1 on ArchLinux
I am interested in setting up custom image for some of the tags I use.
I have tried to use a svg file by setting it in the following ways:
Hello Everyone.
If this is not the place to address this issue, could you please
direct me to the proper forum.
Info: Using Emacs 24.3.1 on ArchLinux
I am interested in setting up custom image for some of the tags I use.
I have tried to use a svg file by setting it in the following ways:
Hello Everyone.
If this is not the place to address this issue, could you please
direct me to the proper forum.
Info: Using Emacs 24.3.1 on ArchLinux
I am interested in setting up custom image for some of the tags I use.
I have tried to use a svg file by setting it in the following ways:
On Thu, Jul 31 2014, Trevor Jim wrote:
> BTW I have been refactoring my async process code. You might consider
> it for your patch.
I'll look at that. I figured out that I might also reuse
notmuch-parser.el. I'll post here my findings later.
-Michal
Austin Clements writes:
> notmuch-poll-script has long since been deprecated in favor of
> post-new hooks, but this wasn't obvious from the documentation.
> Update the documentation to make this clear. Since
> notmuch-poll-script could, to some extend, be used to control the path
> of the
Austin Clements writes:
> ---
> util/string-util.h | 8
> 1 file changed, 8 insertions(+)
pushed this one patch.
d
Mark Oteiza writes:
> Try to read the config parameter user.name from $NAME before taking the
> user name from /etc/passwd.
pushed
d
Mark Oteiza writes:
> Try to read the config parameter database.path from $MAILDIR before
> falling back to $HOME/mail
pushed.
d
David Bremner writes:
> Mark Oteiza writes:
>
>> Try to read the config parameter database.path from $MAILDIR before
>> falling back to $HOME/mail
>> ---
>
> This patch doesn't apply to git master. I'm not really sure happened,
> maybe you generated it against some old version?
Ah, nevermind
Mark Oteiza writes:
> Try to read the config parameter database.path from $MAILDIR before
> falling back to $HOME/mail
> ---
This patch doesn't apply to git master. I'm not really sure happened,
maybe you generated it against some old version?
d
On Thu, Jul 31 2014, Trevor Jim wrote:
BTW I have been refactoring my async process code. You might consider
it for your patch.
I'll look at that. I figured out that I might also reuse
notmuch-parser.el. I'll post here my findings later.
-Michal
___
Mark Oteiza mvote...@udel.edu writes:
Try to read the config parameter database.path from $MAILDIR before
falling back to $HOME/mail
---
This patch doesn't apply to git master. I'm not really sure happened,
maybe you generated it against some old version?
d
Austin Clements amdra...@mit.edu writes:
---
util/string-util.h | 8
1 file changed, 8 insertions(+)
pushed this one patch.
d
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch
Mark Oteiza mvote...@udel.edu writes:
Try to read the config parameter user.name from $NAME before taking the
user name from /etc/passwd.
pushed
d
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch
Mark Oteiza mvote...@udel.edu writes:
Try to read the config parameter database.path from $MAILDIR before
falling back to $HOME/mail
pushed.
d
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch
Austin Clements amdra...@mit.edu writes:
notmuch-poll-script has long since been deprecated in favor of
post-new hooks, but this wasn't obvious from the documentation.
Update the documentation to make this clear. Since
notmuch-poll-script could, to some extend, be used to control the path
Michal Sojka sojk...@fel.cvut.cz writes:
notmuch-company.el hooks itself into message-mode and uses
company-mode to offer the completion to the user. The file is put into
the contrib directory which means that the use has to install it
himself. This is because company-mode is not a part of
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
This is v3 of id:1406652492-27803-1-git-send-email-amdra...@mit.edu.
This fixes one issue and tidies up another thing in
notmuch_database_upgrade I found while working on change tracking
support. Most of the patches are logically identical to v2, but the
changes ripple through the patch context,
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
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 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
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
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
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, 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
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
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
---
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
+++
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
The database schema documentation made it sound like each mail
document had exactly one on-disk message file, which hasn't been true
for a long time.
---
lib/database.cc | 9 ++---
1 file changed, 6 insertions(+), 3 deletions(-)
diff --git a/lib/database.cc b/lib/database.cc
index
Previously, we invalidated stored message metadata in
_notmuch_message_add_term and _notmuch_message_remove_term, but not in
_notmuch_message_gen_terms. This doesn't currently result in any bugs
because of our limited uses of _notmuch_message_gen_terms, but it may
could cause trouble in the
50 matches
Mail list logo
