[PATCH] VIM: Automatically refresh folder screen

2014-12-16 Thread Franz Fellner
David Bremner wrote:
> Ian Main  writes:
> 
> > This patch makes the folder screen refresh each time you 'enter' it.
> > This way when you read a folder and mark items as read the changes are
> > reflected immediately when you return to the folder view.
> 
> It seems to work, but it is pretty slow for large mailboxes. I have
> 27 unread messages and there is a pause of about 1 second when
> returning to the "folder screen".  I'm not sure, maybe the vim interface
> is just overall not usable with such large search results?

I remember the times (not that far away) when paging through the result of a 
query
in the emacs interface resulted in a lock of several seconds after each 
 or
 keypress, even in medium sized queries of 1000 queries. This went away 
in the
meantime.

I just found the issue that caused the lag in the vim interface:
https://github.com/imain/notmuch-vim/commit/649c18122befbabb52082b7d7f77abf863efc62b

Using query.count_messages instead of query.search_messages.count did the trick.

> 
> ___
> notmuch mailing list
> notmuch at notmuchmail.org
> http://notmuchmail.org/mailman/listinfo/notmuch




exim config for 'notmuch insert' retry

2014-12-16 Thread Edward Betts
Short version: exim has an option to retry delivery when notmuch insert fails

Long version:

I'm using maildrop and 'notmuch insert' to sort and tag my incoming mail.
Sometimes 'notmuch insert' isn't able to write to the notmuch index because
another process is holding the notmuch write lock. At first when this happened
exim would just bounce the message.

I could use the '--keep' option so 'notmuch insert' would write the message to
the maildir, but not index it. It would later be picked up by running 'notmuch
new' from cron. The problem is that the initial tagging is defined in the
maildrop config. I would need to specify my tagging rules in two different
places.

For me, a better approach would be if the undeliverable message could be added
to a queue, ready for another delivery attempt. I realised that this is exactly
what an MTA like exim is designed to do. I added the 'temp_errors = 1' option
to the maildrop pipe transport, this tells exim that delivery errors are
temporary and it should retry failed deliveries.

I'm sharing this information in case other people find it useful.

Here is the complete maildrop pipe transport from my exim4.conf:

maildrop_pipe:
  driver = pipe
  path = "/bin:/usr/bin:/usr/local/bin"
  command = "/usr/bin/maildrop"
  temp_errors = 1
  message_prefix =
  message_suffix =
  log_defer_output = true
  return_path_add
  delivery_date_add
  envelope_to_add

-- 
Edward.


Python bindings and Xapian exceptions

2014-12-16 Thread David Bremner
Matt  writes:

> 2014-12-15 21:41 GMT+01:00 David Bremner :
>> Matt  writes:
>>
 > But for exceptions in general, yes the notmuch library does need to be
 > fixed to allow the caller of functions to distinguish between things
 > like "no matches found" and "an exception occurred, so it's unknown if
 > any messages match the search". That's a general class of library
 > interface bugs that all need to be fixed.
>>>
>>> I 've also hit this *API bug* and was wondering if a fix had been done since
>>> then (I use notmuch 0.17) ? I found nothing on http://notmuchmail.org/news/
>>
>> Can you be more specific? I'd say in general no thorough overhaul of
>> error handling has happened, but if you can tell us what particular
>> libnotmuch function (or the equivalient python binding) you are having
>> trouble with, we may be able to give a more informative answer.
>>
>
> For instance when using the python bindings:
> In constructor I do
> self.db = notmuch.Database(self.db_path)
> and there I have a method called periodically that returns:
> returns notmuch.Query(self.db, "tag:unread and tag:inbox").count_messages()
>
> When it fails the previous method returns 0 and displays on stdout/stderr;
> "A Xapian exception occurred: The revision being read has been
> discarded - you should call Xapian::Database::reopen() and retry the
> operation
> Query string was: tag:unread and tag:inbox"

Right, this seems to be a particularly heinous example.

Any objections (or better ideas) from fellow developers to something
along the lines of the following? It isn't a huge improvement, and I
didn't update the other 3 places it's called (or the bindings), but it
seems like a step forward.  I guess something similar should be done for
notmuch_query_count_threads.

Alternatively, we could follow unix tradition and return -1 on error.
The only argument I can see either way at the moment is that fewer error
return styles is better than more.

diff --git a/lib/notmuch.h b/lib/notmuch.h
index 220839b..06228bc 100644
--- a/lib/notmuch.h
+++ b/lib/notmuch.h
@@ -901,8 +901,8 @@ notmuch_threads_destroy (notmuch_threads_t *threads);
  * If a Xapian exception occurs, this function may return 0 (after
  * printing a message).
  */
-unsigned
-notmuch_query_count_messages (notmuch_query_t *query);
+notmuch_status_t
+notmuch_query_count_messages (notmuch_query_t *query, unsigned *count);

 /**
  * Return the number of threads matching a search.
diff --git a/lib/query.cc b/lib/query.cc
index 60ff8bd..a623ea8 100644
--- a/lib/query.cc
+++ b/lib/query.cc
@@ -508,8 +508,8 @@ notmuch_threads_destroy (notmuch_threads_t *threads)
 talloc_free (threads);
 }

-unsigned
-notmuch_query_count_messages (notmuch_query_t *query)
+notmuch_status_t
+notmuch_query_count_messages (notmuch_query_t *query, unsigned *count_out)
 {
 notmuch_database_t *notmuch = query->notmuch;
 const char *query_string = query->query_string;
@@ -562,12 +562,11 @@ notmuch_query_count_messages (notmuch_query_t *query)
count = mset.get_matches_estimated();

 } catch (const Xapian::Error ) {
-   fprintf (stderr, "A Xapian exception occurred: %s\n",
-error.get_msg().c_str());
-   fprintf (stderr, "Query string was: %s\n", query->query_string);
+   return NOTMUCH_STATUS_XAPIAN_EXCEPTION;
 }
-
-return count;
+
+*count_out=count;
+return NOTMUCH_STATUS_SUCCESS;
 }

 unsigned
diff --git a/notmuch-count.c b/notmuch-count.c
index 6058f7c..db43959 100644
--- a/notmuch-count.c
+++ b/notmuch-count.c
@@ -71,6 +71,7 @@ print_count (notmuch_database_t *notmuch, const char 
*query_str,
 {
 notmuch_query_t *query;
 size_t i;
+unsigned count;

 query = notmuch_query_create (notmuch, query_str);
 if (query == NULL) {
@@ -83,7 +84,9 @@ print_count (notmuch_database_t *notmuch, const char 
*query_str,

 switch (output) {
 case OUTPUT_MESSAGES:
-   printf ("%u\n", notmuch_query_count_messages (query));
+   if (notmuch_query_count_messages (query, ))
+   return 1;
+   printf ("%u\n", count);
break;
 case OUTPUT_THREADS:
printf ("%u\n", notmuch_query_count_threads (query));
diff --git a/notmuch-reply.c b/notmuch-reply.c
index 7c1c809..5b7c0e1 100644
--- a/notmuch-reply.c
+++ b/notmuch-reply.c
@@ -650,8 +650,13 @@ notmuch_reply_format_sprinter(void *ctx,
 notmuch_messages_t *messages;
 notmuch_message_t *message;
 mime_node_t *node;
+unsigned count;

-if (notmuch_query_count_messages (query) != 1) {
+if (notmuch_query_count_messages (query, )) {
+   fprintf (stderr, "Error: Xapian exception counting messages.\n");
+   return 1;
+}
+if (count != 1) {
fprintf (stderr, "Error: search term did not match precisely one 
message.\n");
return 1;
 }


Re: Python bindings and Xapian exceptions

2014-12-16 Thread David Bremner
Matt matta...@gmail.com writes:

 2014-12-15 21:41 GMT+01:00 David Bremner da...@tethera.net:
 Matt matta...@gmail.com writes:

  But for exceptions in general, yes the notmuch library does need to be
  fixed to allow the caller of functions to distinguish between things
  like no matches found and an exception occurred, so it's unknown if
  any messages match the search. That's a general class of library
  interface bugs that all need to be fixed.

 I 've also hit this *API bug* and was wondering if a fix had been done since
 then (I use notmuch 0.17) ? I found nothing on http://notmuchmail.org/news/

 Can you be more specific? I'd say in general no thorough overhaul of
 error handling has happened, but if you can tell us what particular
 libnotmuch function (or the equivalient python binding) you are having
 trouble with, we may be able to give a more informative answer.


 For instance when using the python bindings:
 In constructor I do
 self.db = notmuch.Database(self.db_path)
 and there I have a method called periodically that returns:
 returns notmuch.Query(self.db, tag:unread and tag:inbox).count_messages()

 When it fails the previous method returns 0 and displays on stdout/stderr;
 A Xapian exception occurred: The revision being read has been
 discarded - you should call Xapian::Database::reopen() and retry the
 operation
 Query string was: tag:unread and tag:inbox

Right, this seems to be a particularly heinous example.

Any objections (or better ideas) from fellow developers to something
along the lines of the following? It isn't a huge improvement, and I
didn't update the other 3 places it's called (or the bindings), but it
seems like a step forward.  I guess something similar should be done for
notmuch_query_count_threads.

Alternatively, we could follow unix tradition and return -1 on error.
The only argument I can see either way at the moment is that fewer error
return styles is better than more.

diff --git a/lib/notmuch.h b/lib/notmuch.h
index 220839b..06228bc 100644
--- a/lib/notmuch.h
+++ b/lib/notmuch.h
@@ -901,8 +901,8 @@ notmuch_threads_destroy (notmuch_threads_t *threads);
  * If a Xapian exception occurs, this function may return 0 (after
  * printing a message).
  */
-unsigned
-notmuch_query_count_messages (notmuch_query_t *query);
+notmuch_status_t
+notmuch_query_count_messages (notmuch_query_t *query, unsigned *count);
 
 /**
  * Return the number of threads matching a search.
diff --git a/lib/query.cc b/lib/query.cc
index 60ff8bd..a623ea8 100644
--- a/lib/query.cc
+++ b/lib/query.cc
@@ -508,8 +508,8 @@ notmuch_threads_destroy (notmuch_threads_t *threads)
 talloc_free (threads);
 }
 
-unsigned
-notmuch_query_count_messages (notmuch_query_t *query)
+notmuch_status_t
+notmuch_query_count_messages (notmuch_query_t *query, unsigned *count_out)
 {
 notmuch_database_t *notmuch = query-notmuch;
 const char *query_string = query-query_string;
@@ -562,12 +562,11 @@ notmuch_query_count_messages (notmuch_query_t *query)
count = mset.get_matches_estimated();
 
 } catch (const Xapian::Error error) {
-   fprintf (stderr, A Xapian exception occurred: %s\n,
-error.get_msg().c_str());
-   fprintf (stderr, Query string was: %s\n, query-query_string);
+   return NOTMUCH_STATUS_XAPIAN_EXCEPTION;
 }
-
-return count;
+
+*count_out=count;
+return NOTMUCH_STATUS_SUCCESS;
 }
 
 unsigned
diff --git a/notmuch-count.c b/notmuch-count.c
index 6058f7c..db43959 100644
--- a/notmuch-count.c
+++ b/notmuch-count.c
@@ -71,6 +71,7 @@ print_count (notmuch_database_t *notmuch, const char 
*query_str,
 {
 notmuch_query_t *query;
 size_t i;
+unsigned count;
 
 query = notmuch_query_create (notmuch, query_str);
 if (query == NULL) {
@@ -83,7 +84,9 @@ print_count (notmuch_database_t *notmuch, const char 
*query_str,
 
 switch (output) {
 case OUTPUT_MESSAGES:
-   printf (%u\n, notmuch_query_count_messages (query));
+   if (notmuch_query_count_messages (query, count))
+   return 1;
+   printf (%u\n, count);
break;
 case OUTPUT_THREADS:
printf (%u\n, notmuch_query_count_threads (query));
diff --git a/notmuch-reply.c b/notmuch-reply.c
index 7c1c809..5b7c0e1 100644
--- a/notmuch-reply.c
+++ b/notmuch-reply.c
@@ -650,8 +650,13 @@ notmuch_reply_format_sprinter(void *ctx,
 notmuch_messages_t *messages;
 notmuch_message_t *message;
 mime_node_t *node;
+unsigned count;
 
-if (notmuch_query_count_messages (query) != 1) {
+if (notmuch_query_count_messages (query, count)) {
+   fprintf (stderr, Error: Xapian exception counting messages.\n);
+   return 1;
+}
+if (count != 1) {
fprintf (stderr, Error: search term did not match precisely one 
message.\n);
return 1;
 }
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch


exim config for 'notmuch insert' retry

2014-12-16 Thread Edward Betts
Short version: exim has an option to retry delivery when notmuch insert fails

Long version:

I'm using maildrop and 'notmuch insert' to sort and tag my incoming mail.
Sometimes 'notmuch insert' isn't able to write to the notmuch index because
another process is holding the notmuch write lock. At first when this happened
exim would just bounce the message.

I could use the '--keep' option so 'notmuch insert' would write the message to
the maildir, but not index it. It would later be picked up by running 'notmuch
new' from cron. The problem is that the initial tagging is defined in the
maildrop config. I would need to specify my tagging rules in two different
places.

For me, a better approach would be if the undeliverable message could be added
to a queue, ready for another delivery attempt. I realised that this is exactly
what an MTA like exim is designed to do. I added the 'temp_errors = 1' option
to the maildrop pipe transport, this tells exim that delivery errors are
temporary and it should retry failed deliveries.

I'm sharing this information in case other people find it useful.

Here is the complete maildrop pipe transport from my exim4.conf:

maildrop_pipe:
  driver = pipe
  path = /bin:/usr/bin:/usr/local/bin
  command = /usr/bin/maildrop
  temp_errors = 1
  message_prefix =
  message_suffix =
  log_defer_output = true
  return_path_add
  delivery_date_add
  envelope_to_add

-- 
Edward.
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch


Re: [PATCH] VIM: Automatically refresh folder screen

2014-12-16 Thread Franz Fellner
David Bremner wrote:
 Ian Main im...@stemwinder.org writes:
 
  This patch makes the folder screen refresh each time you 'enter' it.
  This way when you read a folder and mark items as read the changes are
  reflected immediately when you return to the folder view.
 
 It seems to work, but it is pretty slow for large mailboxes. I have
 27 unread messages and there is a pause of about 1 second when
 returning to the folder screen.  I'm not sure, maybe the vim interface
 is just overall not usable with such large search results?

I remember the times (not that far away) when paging through the result of a 
query
in the emacs interface resulted in a lock of several seconds after each 
PGDOWN or
DOWN keypress, even in medium sized queries of 1000 queries. This went away 
in the
meantime.

I just found the issue that caused the lag in the vim interface:
https://github.com/imain/notmuch-vim/commit/649c18122befbabb52082b7d7f77abf863efc62b

Using query.count_messages instead of query.search_messages.count did the trick.

 
 ___
 notmuch mailing list
 notmuch@notmuchmail.org
 http://notmuchmail.org/mailman/listinfo/notmuch


___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch