Update to library logging, version 5

This takes into account (most of) Tomi's comments and adds a bunch more tests. We bikeshedded a bit about log_to_string on IRC, and eventually convered on eliminating it. I guess it might be necessary to add a compat version of asprintf for some environments (Solaris?) but this is easy enough

[Patch v5 5/8] lib: add a log function with output to a string in notmuch_database_t

In principle in the future this could do something fancier than sprintf. --- lib/database-private.h | 4 lib/database.cc| 24 lib/notmuch-private.h | 4 lib/notmuch.h | 7 +++ 4 files changed, 39 insertions(+) diff --git

[Patch v5 1/8] test: Add two tests for error output from notmuch_database_open

This is arguably testing the same thing twice, but in the brave new future where we don't use printf anymore, each subcommand will be responsible for handling the output on it's own. --- test/T050-new.sh | 7 +++ test/T150-tagging.sh | 6 ++ 2 files changed, 13 insertions(+) diff

[Patch v5 3/8] test: add error reporting tests

This includes tests for all of the error fprintfs in the library I could figure out how to test without using gdb scripts. It boils down to errors opening files and exceptions caused by corrupted Xapian databases. --- test/T560-lib-error.sh | 250 +

[Patch v5 7/8] lib: replace almost all fprintfs in library with _n_d_log

This is not supposed to change any functionality from an end user point of view. Note that it will eliminate some output to stderr. The query debugging output is left as is; it doesn't really fit with the current primitive logging model. The remaining bad fprintf will need an internal API change.

[Patch v5 6/8] lib: add private function to extract the database for a message.

This is needed by logging in functions outside message.cc that take only a notmuch_message_t object. --- lib/message.cc| 6 ++ lib/notmuch-private.h | 2 ++ 2 files changed, 8 insertions(+) diff --git a/lib/message.cc b/lib/message.cc index 956a70a..b84e5e1 100644 ---

[Patch v5 2/8] test: add support for compiling and running C snippets

This is to limit the copy-pasta involved in running C tests. I decided to keep things simple and not try to provide an actual C skeleton. The setting of LD_LIBRARY_PATH is to force using the built libnotmuch rather than any potential system one. --- test/README | 5 + test/test-lib.sh

[Patch v5 8/8] lib: eliminate fprintf from _notmuch_message_file_open

You may wonder why _notmuch_message_file_open_ctx has two parameters. This is because we need sometime to use a ctx which is a notmuch_message_t. While we could get the database from this, there is no easy way in C to tell type we are getting. --- lib/database.cc | 2 +- lib/message-file.c

[Patch v5 5/8] lib: add a log function with output to a string in notmuch_database_t

In principle in the future this could do something fancier than sprintf. --- lib/database-private.h | 4 lib/database.cc| 24 lib/notmuch-private.h | 4 lib/notmuch.h | 7 +++ 4 files changed, 39 insertions(+) diff --git

[Patch v5 3/8] test: add error reporting tests

This includes tests for all of the error fprintfs in the library I could figure out how to test without using gdb scripts. It boils down to errors opening files and exceptions caused by corrupted Xapian databases. --- test/T560-lib-error.sh | 250 +

[Patch v5 7/8] lib: replace almost all fprintfs in library with _n_d_log

This is not supposed to change any functionality from an end user point of view. Note that it will eliminate some output to stderr. The query debugging output is left as is; it doesn't really fit with the current primitive logging model. The remaining bad fprintf will need an internal API change.

[Patch v5 6/8] lib: add private function to extract the database for a message.

This is needed by logging in functions outside message.cc that take only a notmuch_message_t object. --- lib/message.cc| 6 ++ lib/notmuch-private.h | 2 ++ 2 files changed, 8 insertions(+) diff --git a/lib/message.cc b/lib/message.cc index 956a70a..b84e5e1 100644 ---

[Patch v5 4/8] lib: add verbose versions of notmuch_database_{open,create}

The compatibility wrapper ensures that clients calling notmuch_database_open will receive consistent output for now. The changes to notmuch-{new,search} and test/symbol-test are just to make the test suite pass. The use of IGNORE_RESULT is justified by two things. 1) I don't know what else to

[Patch v5 8/8] lib: eliminate fprintf from _notmuch_message_file_open

You may wonder why _notmuch_message_file_open_ctx has two parameters. This is because we need sometime to use a ctx which is a notmuch_message_t. While we could get the database from this, there is no easy way in C to tell type we are getting. --- lib/database.cc | 2 +- lib/message-file.c

[Patch v5 1/8] test: Add two tests for error output from notmuch_database_open

This is arguably testing the same thing twice, but in the brave new future where we don't use printf anymore, each subcommand will be responsible for handling the output on it's own. --- test/T050-new.sh | 7 +++ test/T150-tagging.sh | 6 ++ 2 files changed, 13 insertions(+) diff

Can't compose message in Emacs - Notmuch

Greetings! Emacs 24.4.1 (Arch Linux if that helps) Notmuch 0.19 The problem is that I can neither compose a new email nor reply to an old email unless I have already used message mode (via Gnus) first. I get an error message - Google on the error message below gets me nowhere! Can anyone give

emacs / vim - time taken to open threads

Hi all, Continuing my journey with notmuch... It has been very enjoyable so far. One thing which has been puzzling me greatly is the time it can take to notmuch-show a moderately sized thread (eg one with 32 messages with a three to four sentence paragraph per message - approx 32 x 35kB with some

Re: emacs / vim - time taken to open threads

Matthew Lear m...@bubblegen.co.uk writes: Despite being a vi guy for years, I prefer the emacs interface to notmuch and really like what it provides. I'm sticking with it but there is clearly a problem and I'd like to solve it. It's annoying when you know that something isn't working as well

Re: strange search behaviour in emacs

I suspect this is related to asynch loading. The first query is still filling into the buffer, and emacs doesn't starting filling the second buffer until the first search finishes. In my experiments it _eventually_ does the second query. You are correct. I confirm that the second query

Re: strange search behaviour in emacs

Sebastian Fischmeister sfisc...@uwaterloo.ca writes: The following *always* returns an empty list, even when I see an email with bar right there in the list after the first search: M-: (notmuch-search from:sfischme) ;;me M-: (notmuch-search bar) I suspect this is related to asynch loading.

Re: Emacs client scalability for long, deeply-nested threads

Jed Brown j...@59a2.org writes: Michael Hudson-Doyle michael.hud...@canonical.com writes: I have encountered this too. A C-u before entering the thread helps (this means already read messages are not rendered I think), as does a M-x notmuch-show-toggle-thread-indentation . Thanks,

Re: Can't compose message in Emacs - Notmuch

Glyn Millington glyn.milling...@gmail.com writes: Greetings! Emacs 24.4.1 (Arch Linux if that helps) Notmuch 0.19 The problem is that I can neither compose a new email nor reply to an old email unless I have already used message mode (via Gnus) first. I get an error message - Google on

Re: Emacs client scalability for long, deeply-nested threads

David Bremner da...@tethera.net writes: How is the performance of tree-view on these threads? tree-view? Loading is about equally slow with/without notmuch-show-indent-messages-width=0. Navigation is pretty fast once loaded. notmuch show --format=sexp for an 1100 message thread with 7.5 MB

Emacs client scalability for long, deeply-nested threads

I have encountered this too. A C-u before entering the thread helps (this means already read messages are not rendered I think), as does a M-x notmuch-show-toggle-thread-indentation . Something less manual would be nice, I guess... On 24 March 2015 at 07:09, Jed Brown wrote: > I occasionally

strange search behaviour in emacs

Hi, I have some strange behaviour when performing searches on notmuch in emacs. The following works just fine: M-: (notmuch-search "from:foo") ;;not me M-: (notmuch-search "bar") The following *always* returns an empty list, even when I see an email with "bar" right there in the list after the

Can't compose message in Emacs - Notmuch

Greetings! Emacs 24.4.1 (Arch Linux if that helps) Notmuch 0.19 The problem is that I can neither compose a new email nor reply to an old email unless I have already used message mode (via Gnus) first. I get an error message - Google on the error message below gets me nowhere! Can anyone give

[BUG] notmuch crashes on FreeBSD when synchronize_flags=true

FYI (VirtualBox FreeBSD_10.1-64bit.7z from http://www.osboxes.org/freebsd/) root at osboxes:~/mail # rm -rf .notmuch/ root at osboxes:~/mail # notmuch new Found 1 total files (that's not much mail). Warning: /root/mail/new/new.mail is an mbox containing a single message, likely caused

[Patch v5 1/8] test: Add two tests for error output from notmuch_database_open

This is arguably testing the same thing twice, but in the brave new future where we don't use printf anymore, each subcommand will be responsible for handling the output on it's own. --- test/T050-new.sh | 7 +++ test/T150-tagging.sh | 6 ++ 2 files changed, 13 insertions(+) diff

[Patch v5 5/8] lib: add a log function with output to a string in notmuch_database_t

In principle in the future this could do something fancier than sprintf. --- lib/database-private.h | 4 lib/database.cc| 24 lib/notmuch-private.h | 4 lib/notmuch.h | 7 +++ 4 files changed, 39 insertions(+) diff --git

[Patch v5 3/8] test: add error reporting tests

This includes tests for all of the error fprintfs in the library I could figure out how to test without using gdb scripts. It boils down to errors opening files and exceptions caused by corrupted Xapian databases. --- test/T560-lib-error.sh | 250 +

[Patch v5 6/8] lib: add private function to extract the database for a message.

This is needed by logging in functions outside message.cc that take only a notmuch_message_t object. --- lib/message.cc| 6 ++ lib/notmuch-private.h | 2 ++ 2 files changed, 8 insertions(+) diff --git a/lib/message.cc b/lib/message.cc index 956a70a..b84e5e1 100644 ---

[Patch v5 4/8] lib: add "verbose" versions of notmuch_database_{open,create}

The compatibility wrapper ensures that clients calling notmuch_database_open will receive consistent output for now. The changes to notmuch-{new,search} and test/symbol-test are just to make the test suite pass. The use of IGNORE_RESULT is justified by two things. 1) I don't know what else to

[Patch v5 8/8] lib: eliminate fprintf from _notmuch_message_file_open

You may wonder why _notmuch_message_file_open_ctx has two parameters. This is because we need sometime to use a ctx which is a notmuch_message_t. While we could get the database from this, there is no easy way in C to tell type we are getting. --- lib/database.cc | 2 +- lib/message-file.c

[Patch v5 2/8] test: add support for compiling and running C snippets

This is to limit the copy-pasta involved in running C tests. I decided to keep things simple and not try to provide an actual C skeleton. The setting of LD_LIBRARY_PATH is to force using the built libnotmuch rather than any potential system one. --- test/README | 5 + test/test-lib.sh

[Patch v5 7/8] lib: replace almost all fprintfs in library with _n_d_log

This is not supposed to change any functionality from an end user point of view. Note that it will eliminate some output to stderr. The query debugging output is left as is; it doesn't really fit with the current primitive logging model. The remaining "bad" fprintf will need an internal API

Update to library logging, version 5

This takes into account (most of) Tomi's comments and adds a bunch more tests. We bikeshedded a bit about log_to_string on IRC, and eventually convered on eliminating it. I guess it might be necessary to add a compat version of asprintf for some environments (Solaris?) but this is easy enough

[Patch v5 3/8] test: add error reporting tests

This includes tests for all of the error fprintfs in the library I could figure out how to test without using gdb scripts. It boils down to errors opening files and exceptions caused by corrupted Xapian databases. --- test/T560-lib-error.sh | 250 +

[Patch v5 5/8] lib: add a log function with output to a string in notmuch_database_t

In principle in the future this could do something fancier than sprintf. --- lib/database-private.h | 4 lib/database.cc| 24 lib/notmuch-private.h | 4 lib/notmuch.h | 7 +++ 4 files changed, 39 insertions(+) diff --git

[Patch v5 4/8] lib: add "verbose" versions of notmuch_database_{open,create}

The compatibility wrapper ensures that clients calling notmuch_database_open will receive consistent output for now. The changes to notmuch-{new,search} and test/symbol-test are just to make the test suite pass. The use of IGNORE_RESULT is justified by two things. 1) I don't know what else to

[Patch v5 1/8] test: Add two tests for error output from notmuch_database_open

This is arguably testing the same thing twice, but in the brave new future where we don't use printf anymore, each subcommand will be responsible for handling the output on it's own. --- test/T050-new.sh | 7 +++ test/T150-tagging.sh | 6 ++ 2 files changed, 13 insertions(+) diff

[Patch v5 2/8] test: add support for compiling and running C snippets

This is to limit the copy-pasta involved in running C tests. I decided to keep things simple and not try to provide an actual C skeleton. The setting of LD_LIBRARY_PATH is to force using the built libnotmuch rather than any potential system one. --- test/README | 5 + test/test-lib.sh

[Patch v5 7/8] lib: replace almost all fprintfs in library with _n_d_log

This is not supposed to change any functionality from an end user point of view. Note that it will eliminate some output to stderr. The query debugging output is left as is; it doesn't really fit with the current primitive logging model. The remaining "bad" fprintf will need an internal API

[Patch v5 6/8] lib: add private function to extract the database for a message.

This is needed by logging in functions outside message.cc that take only a notmuch_message_t object. --- lib/message.cc| 6 ++ lib/notmuch-private.h | 2 ++ 2 files changed, 8 insertions(+) diff --git a/lib/message.cc b/lib/message.cc index 956a70a..b84e5e1 100644 ---

[Patch v5 8/8] lib: eliminate fprintf from _notmuch_message_file_open

You may wonder why _notmuch_message_file_open_ctx has two parameters. This is because we need sometime to use a ctx which is a notmuch_message_t. While we could get the database from this, there is no easy way in C to tell type we are getting. --- lib/database.cc | 2 +- lib/message-file.c

Can't compose message in Emacs - Notmuch

Glyn Millington writes: > Greetings! > > Emacs 24.4.1 (Arch Linux if that helps) > Notmuch 0.19 > > The problem is that I can neither compose a new email nor reply to an old > email unless I have already used message mode (via Gnus) first. > I get an error message - Google on the error message

strange search behaviour in emacs

Sebastian Fischmeister writes: > The following *always* returns an empty list, even when I see an email > with "bar" right there in the list after the first search: > > M-: (notmuch-search "from:sfischme") ;;me > M-: (notmuch-search "bar") I suspect this is related to asynch loading. The first

Emacs client scalability for long, deeply-nested threads

Jed Brown writes: > Michael Hudson-Doyle writes: > >> I have encountered this too. A C-u before entering the thread helps >> (this means already read messages are not rendered I think), as does a >> M-x notmuch-show-toggle-thread-indentation . > > Thanks, Michael. This does help, though it

Emacs client scalability for long, deeply-nested threads

plication/pgp-signature Size: 818 bytes Desc: not available URL: <http://notmuchmail.org/pipermail/notmuch/attachments/20150324/d51317ca/attachment.pgp>

emacs / vim - time taken to open threads

Hi all, Continuing my journey with notmuch... It has been very enjoyable so far. One thing which has been puzzling me greatly is the time it can take to notmuch-show a moderately sized thread (eg one with 32 messages with a three to four sentence paragraph per message - approx 32 x 35kB with some

emacs / vim - time taken to open threads

Matthew Lear writes: > > Despite being a vi guy for years, I prefer the emacs interface to > notmuch and really like what it provides. I'm sticking with it but there > is clearly a problem and I'd like to solve it. It's annoying when you > know that something isn't working as well as it should

strange search behaviour in emacs

> I suspect this is related to asynch loading. The first query is still > filling into the buffer, and emacs doesn't starting filling the second > buffer until the first search finishes. In my experiments it > _eventually_ does the second query. You are correct. I confirm that the second query