[PATCH] man: add references to maildir flag synchronization
On Sun, 26 Feb 2012 00:57:23 +0200, Jani Nikula wrote: > notmuch new, restore, and tag commands support maildir flag > synchronization with notmuch tags. Reference the notmuch-config(1) man > page about it in the relevant man pages. Pushed d
[PATCH] man: document the notmuch configuration settings in notmuch-config(1)
On Sun, 26 Feb 2012 00:23:41 +0200, Jani Nikula wrote: > At the risk of duplication between the man page and the configuration > file generated by default, document the notmuch configuration options > in the notmuch config man page. Pushed. d
[PATCH] emacs: Fix out of date comment
On Sat, 25 Feb 2012 09:50:26 -0500, Austin Clements wrote: > The behavior of the header line in show-mode changed from showing the > subject of the first open message to showing the subject of the first > message in 4d77f18b. Update a comment to reflect this. Pushed. d
[PATCH v2 1/8] Document the JSON schemata used by show and search
On Sun, 19 Feb 2012 19:26:23 -0500, Austin Clements wrote: > --- > devel/schemata | 138 > ++ > notmuch-search.c |3 + > notmuch-show.c |2 + Pushed just the first in the series. d
[PATCH 2/6] NEWS: sync 'new.ignore' entry with its comment in notmuch-config.c
On Sun, 19 Feb 2012 21:47:52 +0100, Pieter Praet wrote: > See previous commit. Pushed. d
[PATCH 1/6] cli: update 'new.ignore' config file comment wrt file/directory matching
On Sun, 19 Feb 2012 21:47:51 +0100, Pieter Praet wrote: > --- > notmuch-config.c |5 - > 1 files changed, 4 insertions(+), 1 deletions(-) pushed.
[PATCH] Build-Depend on libgmime-2.6-dev | libgmime2.4-dev
On Thu, 9 Feb 2012 18:20:20 -0500, Daniel Kahn Gillmor wrote: > libgmime-2.6-dev entered debian unstable today. If 2.6 is available, > notmuch should build against 2.6 instead of 2.4, as 2.6 is the current > upstream stable version of libgmime. Pushed. d
[PATCH 2/2 v2] emacs: Prefer '[No Subject]' to blank subjects.
On Mon, 30 Jan 2012 10:16:01 +, David Edmondson wrote: > --- > emacs/notmuch-lib.el |9 + > emacs/notmuch-print.el |8 ++-- > emacs/notmuch-show.el |5 - > emacs/notmuch.el | 21 + > 4 files changed, 28 insertions(+), 15 deletions(-) Jameson and Antoine have asked for this patch to be reverted. As far as I understand it the printing code actually crashes on blank subjects if this patch is removed, so it seems to me that that (slightly) outweighs the annoyance caused by printing [No Subject]. I don't find the argument that different people are annoyed I'd be willing to be convinced otherwise, but as it turns out the question is somewhat academic; there have been enough changes that this patch no longer reverts cleanly. So Someone (TM) will have to do some to change the behaviour; it sounds like the sensible thing to do would be to move notmuch-prettify-subject into notmuch-print.el and call it there. d
[Patch v6 00/13] Add NOTMUCH_MESSAGE_FLAG_EXCLUDED flag
Quoth Mark Walters on Feb 25 at 8:06 am: > > Here is the latest version of the series. It fixes all of Austin's > review comments. I don't think there are any significant outstanding > issues. LGTM.
[PATCH v5 00/12] emacs: more flexible and consistent tagging operations
On Sat, 25 Feb 2012 12:20:31 -0400, David Bremner wrote: > On Fri, 24 Feb 2012 00:07:27 +0100, Pieter Praet wrote: > > On Wed, 08 Feb 2012 11:58:32 -0400, David Bremner > > wrote: > > > On Sun, 5 Feb 2012 11:13:41 +0400, Dmitry Kurochkin > > gmail.com> wrote: > > > > How about if '*' applies to all messages (as it currently does), > > but 'C-u *' only to open messages? That would make more sense IMHO. > > > > But, conforming to your original request, I've implemented the inverse. > > > > Thanks for implementing that. I could live with either way. Do other > people have opinions on this? My reasoning is if you descend into a > thread from some search page, it seems likely that you want to operate > on the messages matching the search. I've pretty soon lost the original open/close status as I often navigate through messages by opening/closing messages, so for me not operating on all messages in thread is magic behaviour. In case I'd use C-u * I first have to check through the full thread what are the actual messages currently open (lots of screen scrolling :( ) So, I prefer '*' operating on all messages in a thread and C-u '*' for all open messages in a thread. > > d Tomi
[afew] announcing afew, an universal tagging solution with some fancy features
I'm tring to figure out how to use afew. It looks interesting, but gives me surprising results. I did `afew --learn spam -- tag:spam` and believe this tells afew that all the messages matching tag:spam should be classified as spam. But if that is right, why would `afew -c spam -- tag:spam` then show me a bunch of messages that are tagged spam by notmuch but not classified spam by afew? How do I train afew when I correct it's mistakes? Is that what `afew update` is for? What does "update the reference category" mean? Thanks much, James
Regarding notmuch and Fedora 16
On Mon, 27 Feb 2012 09:42:36 +0100, Karel Zak wrote: > > It seems that we have officially notmuch 0.11 in Fedora 17/rawhide, if > you have the latest stable Fedora 16, then you can use: > > yum --enablerepo=rawhide install notmuch notmuch-devel > > to get: > > $ rpm -q notmuch gmime > notmuch-0.11-1.fc17.x86_64 > gmime-2.5.8-1.fc16.x86_64 Great thing -- I'm just wary of using that gmime version with notmuch: check id:"1329840343-10026-1-git-send-email-schnouki at schnouki.net" So, so far I'll run notmuch on Fedora 16 using gmime-2.4.25 (Well, I also use notmuch 0.11.1+239~g4d2d96b ;) > Karel Tomi > > -- > Karel Zak > http://karelzak.blogspot.com
[PATCH 3/3] new: Print final fatal error message to stderr
This was going to stdout. I removed the newline at the beginning of
printing the fatal error message because it wouldn't make sense if you
were only looking at the stderr stream (e.g., you had redirected
stdout to /dev/null).
---
notmuch-new.c |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/notmuch-new.c b/notmuch-new.c
index 0cbd479..9ad790d 100644
--- a/notmuch-new.c
+++ b/notmuch-new.c
@@ -1029,8 +1029,8 @@ notmuch_new_command (void *ctx, int argc, char *argv[])
printf ("\n");
if (ret)
- printf ("\nNote: A fatal error was encountered: %s\n",
- notmuch_status_to_string (ret));
+ fprintf (stderr, "Note: A fatal error was encountered: %s\n",
+notmuch_status_to_string (ret));
notmuch_database_close (notmuch);
--
1.7.7.3
[PATCH 2/3] new: Handle fatal errors in remove_filename and _remove_directory
Previously such errors were simply ignored. Now they cause an
immediate cleanup and abort.
---
notmuch-new.c | 24 ++--
1 files changed, 18 insertions(+), 6 deletions(-)
diff --git a/notmuch-new.c b/notmuch-new.c
index bd9786a..0cbd479 100644
--- a/notmuch-new.c
+++ b/notmuch-new.c
@@ -780,8 +780,10 @@ remove_filename (notmuch_database_t *notmuch,
add_files_state->renamed_messages++;
if (add_files_state->synchronize_flags == TRUE)
notmuch_message_maildir_flags_to_tags (message);
-} else
+ status = NOTMUCH_STATUS_SUCCESS;
+} else if (status == NOTMUCH_STATUS_SUCCESS) {
add_files_state->removed_messages++;
+}
notmuch_message_destroy (message);
notmuch_database_end_atomic (notmuch);
return status;
@@ -789,12 +791,13 @@ remove_filename (notmuch_database_t *notmuch,
/* Recursively remove all filenames from the database referring to
* 'path' (or to any of its children). */
-static void
+static notmuch_status_t
_remove_directory (void *ctx,
notmuch_database_t *notmuch,
const char *path,
add_files_state_t *add_files_state)
{
+notmuch_status_t status;
notmuch_directory_t *directory;
notmuch_filenames_t *files, *subdirs;
char *absolute;
@@ -807,8 +810,10 @@ _remove_directory (void *ctx,
{
absolute = talloc_asprintf (ctx, "%s/%s", path,
notmuch_filenames_get (files));
- remove_filename (notmuch, absolute, add_files_state);
+ status = remove_filename (notmuch, absolute, add_files_state);
talloc_free (absolute);
+ if (status)
+ return status;
}
for (subdirs = notmuch_directory_get_child_directories (directory);
@@ -817,11 +822,14 @@ _remove_directory (void *ctx,
{
absolute = talloc_asprintf (ctx, "%s/%s", path,
notmuch_filenames_get (subdirs));
- _remove_directory (ctx, notmuch, absolute, add_files_state);
+ status = _remove_directory (ctx, notmuch, absolute, add_files_state);
talloc_free (absolute);
+ if (status)
+ return status;
}
notmuch_directory_destroy (directory);
+return NOTMUCH_STATUS_SUCCESS;
}
int
@@ -939,7 +947,9 @@ notmuch_new_command (void *ctx, int argc, char *argv[])
gettimeofday (_start, NULL);
for (f = add_files_state.removed_files->head; f && !interrupted; f =
f->next) {
- remove_filename (notmuch, f->filename, _files_state);
+ ret = remove_filename (notmuch, f->filename, _files_state);
+ if (ret)
+ goto DONE;
if (do_print_progress) {
do_print_progress = 0;
generic_print_progress ("Cleaned up", "messages",
@@ -950,7 +960,9 @@ notmuch_new_command (void *ctx, int argc, char *argv[])
gettimeofday (_start, NULL);
for (f = add_files_state.removed_directories->head, i = 0; f &&
!interrupted; f = f->next, i++) {
- _remove_directory (ctx, notmuch, f->filename, _files_state);
+ ret = _remove_directory (ctx, notmuch, f->filename, _files_state);
+ if (ret)
+ goto DONE;
if (do_print_progress) {
do_print_progress = 0;
generic_print_progress ("Cleaned up", "directories",
--
1.7.7.3
[PATCH 1/3] new: Consistently treat fatal errors as fatal
Previously, fatal errors in add_files_recursive were not treated as
fatal by its callers (including itself!) and add_files_recursive
sometimes returned errors on non-fatal conditions. This makes
add_files_recursive errors consistently fatal and updates all callers
to treat them as fatal.
---
notmuch-new.c | 13 -
1 files changed, 8 insertions(+), 5 deletions(-)
diff --git a/notmuch-new.c b/notmuch-new.c
index 4f13535..bd9786a 100644
--- a/notmuch-new.c
+++ b/notmuch-new.c
@@ -308,7 +308,6 @@ add_files_recursive (notmuch_database_t *notmuch,
if (num_fs_entries == -1) {
fprintf (stderr, "Error opening directory %s: %s\n",
path, strerror (errno));
- ret = NOTMUCH_STATUS_FILE_ERROR;
goto DONE;
}
@@ -351,8 +350,10 @@ add_files_recursive (notmuch_database_t *notmuch,
next = talloc_asprintf (notmuch, "%s/%s", path, entry->d_name);
status = add_files_recursive (notmuch, next, state);
- if (status && ret == NOTMUCH_STATUS_SUCCESS)
+ if (status) {
ret = status;
+ goto DONE;
+ }
talloc_free (next);
next = NULL;
}
@@ -933,6 +934,8 @@ notmuch_new_command (void *ctx, int argc, char *argv[])
}
ret = add_files (notmuch, db_path, _files_state);
+if (ret)
+ goto DONE;
gettimeofday (_start, NULL);
for (f = add_files_state.removed_files->head; f && !interrupted; f =
f->next) {
@@ -965,6 +968,7 @@ notmuch_new_command (void *ctx, int argc, char *argv[])
}
}
+ DONE:
talloc_free (add_files_state.removed_files);
talloc_free (add_files_state.removed_directories);
talloc_free (add_files_state.directory_mtimes);
@@ -1012,10 +1016,9 @@ notmuch_new_command (void *ctx, int argc, char *argv[])
printf ("\n");
-if (ret) {
- printf ("\nNote: At least one error was encountered: %s\n",
+if (ret)
+ printf ("\nNote: A fatal error was encountered: %s\n",
notmuch_status_to_string (ret));
-}
notmuch_database_close (notmuch);
--
1.7.7.3
[PATCH 0/3] Fix some error handling in notmuch new
This series cleans up some bad error handling in notmuch new. In many cases, fatal errors were being ignored, sometimes blatantly and sometimes because the caller did not treat them as fatal even if the callee did.
[RFC PATCH 0/2] natural language date range search
On Sat, 25 Feb 2012 21:53:27 +0200, Jani Nikula wrote: > On Sat, 25 Feb 2012 17:05:44 +0200, Tomi Ollila wrote: [ ... ] > > > > By seeing the thoughts thrown in IRC there seems to be plenty if things > > to resolve until something like this is going to be available in stock > > notmuch. In the meanwhile I provide some ideas into the soup; maybe > > our collective mind can have some use of this. > > > > > > Q: Could 'date:timestr' be converted to 'date:timestr..timestr' ? > > AFAICT this would require the custom query parser. So, maybe someday... :) > > In this idea - means relative time and absolute > > time. The the time string consists of number and letter and assume > > the above suggestion for date:timestr (<- == date:timestr..timestr) > > Letters are s seconds h hours d days w weeks m months (more > > useful than for minutes) and y years. > > I'll put it bluntly: show me the code! ;) I would not have expected nothing less ;) > I'll comment below how your examples can be expressed with working code > in this series, just for comparison, and to show what can be done with > this. Great! Those features suits to my needs just fine; last day is most often needed, then parhaps I jump to one week. 5w is good for ~one month. More "absolute" times (like last november / since last november) are so seldomly needed that writing a bit more is not an issue :D [ ... ] > > BR, > Jani. Tomi
Regarding notmuch and Fedora 16
On Thu, Jan 12, 2012 at 02:31:39PM +0200, Tomi Ollila wrote: > On Tue, 03 Jan 2012 22:36:59 +, Darren McGuicken fernseed.info> wrote: > > On Tue, 03 Jan 2012 17:09:39 -0500, Peter Portante > gmail.com> wrote: > > > I am interested in using notmuch from within emacs, but have not been > > > able to get the latest version of notmuch (0.10.2) to compile under > > > Fedora 16. > > > > Looks like we have a growing Fedora community, yay! :-) > > > > And it's nothing you're doing wrong, per my reply to the other thread > > F16 is using the current development version of gmime which has API > > differences with the stable version 2.4. The patch that exists isn't > > part of standard notmuch since it in turn breaks 2.4 compatibility. > > > > What's the right way to handle this? I see 2.6 tarballs on gnome... is > > 2.6 officially out there and stable? > > Some conditional compilation by #if(def)ing some *GMIME* macro... > > While doing something else I passed by these messages: > > http://www.mail-archive.com/notmuch at notmuchmail.org/msg05829.html > http://koji.fedoraproject.org/koji/buildinfo?buildID=269819 > > These seems to provide valuable information to anyone attempting > to compile notmuch with gmime 2.5+ It seems that we have officially notmuch 0.11 in Fedora 17/rawhide, if you have the latest stable Fedora 16, then you can use: yum --enablerepo=rawhide install notmuch notmuch-devel to get: $ rpm -q notmuch gmime notmuch-0.11-1.fc17.x86_64 gmime-2.5.8-1.fc16.x86_64 Karel -- Karel Zak http://karelzak.blogspot.com
[ANNOUNCE] mutt with notmuch support
On Tue, Jan 03, 2012 at 01:39:38PM +0100, Karel Zak wrote: > This is not another curses front-end for notmuch, this is mutt :-) > More information: > > https://github.com/karelzak/mutt-kz/wiki > > https://raw.github.com/karelzak/mutt-kz/master/README.notmuch We have mailing list now: https://admin.fedoraproject.org/mailman/listinfo/mutt-kz Karel -- Karel Zak http://karelzak.blogspot.com
Re: [ANNOUNCE] mutt with notmuch support
On Tue, Jan 03, 2012 at 01:39:38PM +0100, Karel Zak wrote: This is not another curses front-end for notmuch, this is mutt :-) More information: https://github.com/karelzak/mutt-kz/wiki https://raw.github.com/karelzak/mutt-kz/master/README.notmuch We have mailing list now: https://admin.fedoraproject.org/mailman/listinfo/mutt-kz Karel -- Karel Zak k...@redhat.com http://karelzak.blogspot.com ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
Re: Regarding notmuch and Fedora 16
On Thu, Jan 12, 2012 at 02:31:39PM +0200, Tomi Ollila wrote: On Tue, 03 Jan 2012 22:36:59 +, Darren McGuicken mailing-notm...@fernseed.info wrote: On Tue, 03 Jan 2012 17:09:39 -0500, Peter Portante peter.a.porta...@gmail.com wrote: I am interested in using notmuch from within emacs, but have not been able to get the latest version of notmuch (0.10.2) to compile under Fedora 16. Looks like we have a growing Fedora community, yay! :-) And it's nothing you're doing wrong, per my reply to the other thread F16 is using the current development version of gmime which has API differences with the stable version 2.4. The patch that exists isn't part of standard notmuch since it in turn breaks 2.4 compatibility. What's the right way to handle this? I see 2.6 tarballs on gnome... is 2.6 officially out there and stable? Some conditional compilation by #if(def)ing some *GMIME* macro... While doing something else I passed by these messages: http://www.mail-archive.com/notmuch@notmuchmail.org/msg05829.html http://koji.fedoraproject.org/koji/buildinfo?buildID=269819 These seems to provide valuable information to anyone attempting to compile notmuch with gmime 2.5+ It seems that we have officially notmuch 0.11 in Fedora 17/rawhide, if you have the latest stable Fedora 16, then you can use: yum --enablerepo=rawhide install notmuch notmuch-devel to get: $ rpm -q notmuch gmime notmuch-0.11-1.fc17.x86_64 gmime-2.5.8-1.fc16.x86_64 Karel -- Karel Zak k...@redhat.com http://karelzak.blogspot.com ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
Re: Regarding notmuch and Fedora 16
On Mon, 27 Feb 2012 09:42:36 +0100, Karel Zak k...@redhat.com wrote: It seems that we have officially notmuch 0.11 in Fedora 17/rawhide, if you have the latest stable Fedora 16, then you can use: yum --enablerepo=rawhide install notmuch notmuch-devel to get: $ rpm -q notmuch gmime notmuch-0.11-1.fc17.x86_64 gmime-2.5.8-1.fc16.x86_64 Great thing -- I'm just wary of using that gmime version with notmuch: check id:1329840343-10026-1-git-send-email-schno...@schnouki.net So, so far I'll run notmuch on Fedora 16 using gmime-2.4.25 (Well, I also use notmuch 0.11.1+239~g4d2d96b ;) Karel Tomi -- Karel Zak k...@redhat.com http://karelzak.blogspot.com ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
Re: [PATCH v5 00/12] emacs: more flexible and consistent tagging operations
On Sat, 25 Feb 2012 12:20:31 -0400, David Bremner da...@tethera.net wrote: On Fri, 24 Feb 2012 00:07:27 +0100, Pieter Praet pie...@praet.org wrote: On Wed, 08 Feb 2012 11:58:32 -0400, David Bremner da...@tethera.net wrote: On Sun, 5 Feb 2012 11:13:41 +0400, Dmitry Kurochkin dmitry.kuroch...@gmail.com wrote: How about if '*' applies to all messages (as it currently does), but 'C-u *' only to open messages? That would make more sense IMHO. But, conforming to your original request, I've implemented the inverse. Thanks for implementing that. I could live with either way. Do other people have opinions on this? My reasoning is if you descend into a thread from some search page, it seems likely that you want to operate on the messages matching the search. I've pretty soon lost the original open/close status as I often navigate through messages by opening/closing messages, so for me not operating on all messages in thread is magic behaviour. In case I'd use C-u * I first have to check through the full thread what are the actual messages currently open (lots of screen scrolling :( ) So, I prefer '*' operating on all messages in a thread and C-u '*' for all open messages in a thread. d Tomi ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
[PATCH 1/3] new: Consistently treat fatal errors as fatal
Previously, fatal errors in add_files_recursive were not treated as
fatal by its callers (including itself!) and add_files_recursive
sometimes returned errors on non-fatal conditions. This makes
add_files_recursive errors consistently fatal and updates all callers
to treat them as fatal.
---
notmuch-new.c | 13 -
1 files changed, 8 insertions(+), 5 deletions(-)
diff --git a/notmuch-new.c b/notmuch-new.c
index 4f13535..bd9786a 100644
--- a/notmuch-new.c
+++ b/notmuch-new.c
@@ -308,7 +308,6 @@ add_files_recursive (notmuch_database_t *notmuch,
if (num_fs_entries == -1) {
fprintf (stderr, Error opening directory %s: %s\n,
path, strerror (errno));
- ret = NOTMUCH_STATUS_FILE_ERROR;
goto DONE;
}
@@ -351,8 +350,10 @@ add_files_recursive (notmuch_database_t *notmuch,
next = talloc_asprintf (notmuch, %s/%s, path, entry-d_name);
status = add_files_recursive (notmuch, next, state);
- if (status ret == NOTMUCH_STATUS_SUCCESS)
+ if (status) {
ret = status;
+ goto DONE;
+ }
talloc_free (next);
next = NULL;
}
@@ -933,6 +934,8 @@ notmuch_new_command (void *ctx, int argc, char *argv[])
}
ret = add_files (notmuch, db_path, add_files_state);
+if (ret)
+ goto DONE;
gettimeofday (tv_start, NULL);
for (f = add_files_state.removed_files-head; f !interrupted; f =
f-next) {
@@ -965,6 +968,7 @@ notmuch_new_command (void *ctx, int argc, char *argv[])
}
}
+ DONE:
talloc_free (add_files_state.removed_files);
talloc_free (add_files_state.removed_directories);
talloc_free (add_files_state.directory_mtimes);
@@ -1012,10 +1016,9 @@ notmuch_new_command (void *ctx, int argc, char *argv[])
printf (\n);
-if (ret) {
- printf (\nNote: At least one error was encountered: %s\n,
+if (ret)
+ printf (\nNote: A fatal error was encountered: %s\n,
notmuch_status_to_string (ret));
-}
notmuch_database_close (notmuch);
--
1.7.7.3
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch
[PATCH 0/3] Fix some error handling in notmuch new
This series cleans up some bad error handling in notmuch new. In many cases, fatal errors were being ignored, sometimes blatantly and sometimes because the caller did not treat them as fatal even if the callee did. ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
[PATCH 2/3] new: Handle fatal errors in remove_filename and _remove_directory
Previously such errors were simply ignored. Now they cause an
immediate cleanup and abort.
---
notmuch-new.c | 24 ++--
1 files changed, 18 insertions(+), 6 deletions(-)
diff --git a/notmuch-new.c b/notmuch-new.c
index bd9786a..0cbd479 100644
--- a/notmuch-new.c
+++ b/notmuch-new.c
@@ -780,8 +780,10 @@ remove_filename (notmuch_database_t *notmuch,
add_files_state-renamed_messages++;
if (add_files_state-synchronize_flags == TRUE)
notmuch_message_maildir_flags_to_tags (message);
-} else
+ status = NOTMUCH_STATUS_SUCCESS;
+} else if (status == NOTMUCH_STATUS_SUCCESS) {
add_files_state-removed_messages++;
+}
notmuch_message_destroy (message);
notmuch_database_end_atomic (notmuch);
return status;
@@ -789,12 +791,13 @@ remove_filename (notmuch_database_t *notmuch,
/* Recursively remove all filenames from the database referring to
* 'path' (or to any of its children). */
-static void
+static notmuch_status_t
_remove_directory (void *ctx,
notmuch_database_t *notmuch,
const char *path,
add_files_state_t *add_files_state)
{
+notmuch_status_t status;
notmuch_directory_t *directory;
notmuch_filenames_t *files, *subdirs;
char *absolute;
@@ -807,8 +810,10 @@ _remove_directory (void *ctx,
{
absolute = talloc_asprintf (ctx, %s/%s, path,
notmuch_filenames_get (files));
- remove_filename (notmuch, absolute, add_files_state);
+ status = remove_filename (notmuch, absolute, add_files_state);
talloc_free (absolute);
+ if (status)
+ return status;
}
for (subdirs = notmuch_directory_get_child_directories (directory);
@@ -817,11 +822,14 @@ _remove_directory (void *ctx,
{
absolute = talloc_asprintf (ctx, %s/%s, path,
notmuch_filenames_get (subdirs));
- _remove_directory (ctx, notmuch, absolute, add_files_state);
+ status = _remove_directory (ctx, notmuch, absolute, add_files_state);
talloc_free (absolute);
+ if (status)
+ return status;
}
notmuch_directory_destroy (directory);
+return NOTMUCH_STATUS_SUCCESS;
}
int
@@ -939,7 +947,9 @@ notmuch_new_command (void *ctx, int argc, char *argv[])
gettimeofday (tv_start, NULL);
for (f = add_files_state.removed_files-head; f !interrupted; f =
f-next) {
- remove_filename (notmuch, f-filename, add_files_state);
+ ret = remove_filename (notmuch, f-filename, add_files_state);
+ if (ret)
+ goto DONE;
if (do_print_progress) {
do_print_progress = 0;
generic_print_progress (Cleaned up, messages,
@@ -950,7 +960,9 @@ notmuch_new_command (void *ctx, int argc, char *argv[])
gettimeofday (tv_start, NULL);
for (f = add_files_state.removed_directories-head, i = 0; f
!interrupted; f = f-next, i++) {
- _remove_directory (ctx, notmuch, f-filename, add_files_state);
+ ret = _remove_directory (ctx, notmuch, f-filename, add_files_state);
+ if (ret)
+ goto DONE;
if (do_print_progress) {
do_print_progress = 0;
generic_print_progress (Cleaned up, directories,
--
1.7.7.3
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch
[PATCH 3/3] new: Print final fatal error message to stderr
This was going to stdout. I removed the newline at the beginning of printing the fatal error message because it wouldn't make sense if you were only looking at the stderr stream (e.g., you had redirected stdout to /dev/null). --- notmuch-new.c |4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-) diff --git a/notmuch-new.c b/notmuch-new.c index 0cbd479..9ad790d 100644 --- a/notmuch-new.c +++ b/notmuch-new.c @@ -1029,8 +1029,8 @@ notmuch_new_command (void *ctx, int argc, char *argv[]) printf (\n); if (ret) - printf (\nNote: A fatal error was encountered: %s\n, - notmuch_status_to_string (ret)); + fprintf (stderr, Note: A fatal error was encountered: %s\n, +notmuch_status_to_string (ret)); notmuch_database_close (notmuch); -- 1.7.7.3 ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
Re: [afew] announcing afew, an universal tagging solution with some fancy features
I'm tring to figure out how to use afew. It looks interesting, but gives me surprising results. I did `afew --learn spam -- tag:spam` and believe this tells afew that all the messages matching tag:spam should be classified as spam. But if that is right, why would `afew -c spam -- tag:spam` then show me a bunch of messages that are tagged spam by notmuch but not classified spam by afew? How do I train afew when I correct it's mistakes? Is that what `afew update` is for? What does update the reference category mean? Thanks much, James ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
Re: [Patch v6 00/13] Add NOTMUCH_MESSAGE_FLAG_EXCLUDED flag
Quoth Mark Walters on Feb 25 at 8:06 am: Here is the latest version of the series. It fixes all of Austin's review comments. I don't think there are any significant outstanding issues. LGTM. ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
Thread by subject, at least through API?
I would like to thread some mails by subject, can I do this: get to the data and forge threads between messages that don't otherwise have any References or In-Reply-To:s? Basically I want to make mails with Subject: XYZZY Re: foobar replies to those without Re:. ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
Re: [PATCH 2/2 v2] emacs: Prefer '[No Subject]' to blank subjects.
On Mon, 30 Jan 2012 10:16:01 +, David Edmondson d...@dme.org wrote: --- emacs/notmuch-lib.el |9 + emacs/notmuch-print.el |8 ++-- emacs/notmuch-show.el |5 - emacs/notmuch.el | 21 + 4 files changed, 28 insertions(+), 15 deletions(-) Jameson and Antoine have asked for this patch to be reverted. As far as I understand it the printing code actually crashes on blank subjects if this patch is removed, so it seems to me that that (slightly) outweighs the annoyance caused by printing [No Subject]. I don't find the argument that different people are annoyed I'd be willing to be convinced otherwise, but as it turns out the question is somewhat academic; there have been enough changes that this patch no longer reverts cleanly. So Someone (TM) will have to do some to change the behaviour; it sounds like the sensible thing to do would be to move notmuch-prettify-subject into notmuch-print.el and call it there. d ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
Re: [PATCH] Build-Depend on libgmime-2.6-dev | libgmime2.4-dev
On Thu, 9 Feb 2012 18:20:20 -0500, Daniel Kahn Gillmor d...@fifthhorseman.net wrote: libgmime-2.6-dev entered debian unstable today. If 2.6 is available, notmuch should build against 2.6 instead of 2.4, as 2.6 is the current upstream stable version of libgmime. Pushed. d ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
Re: [PATCH 1/6] cli: update 'new.ignore' config file comment wrt file/directory matching
On Sun, 19 Feb 2012 21:47:51 +0100, Pieter Praet pie...@praet.org wrote: --- notmuch-config.c |5 - 1 files changed, 4 insertions(+), 1 deletions(-) pushed. ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
Re: [PATCH 2/6] NEWS: sync 'new.ignore' entry with its comment in notmuch-config.c
On Sun, 19 Feb 2012 21:47:52 +0100, Pieter Praet pie...@praet.org wrote: See previous commit. Pushed. d ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
Re: [PATCH v2 1/8] Document the JSON schemata used by show and search
On Sun, 19 Feb 2012 19:26:23 -0500, Austin Clements amdra...@mit.edu wrote: --- devel/schemata | 138 ++ notmuch-search.c |3 + notmuch-show.c |2 + Pushed just the first in the series. d ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
Re: [PATCH] emacs: Fix out of date comment
On Sat, 25 Feb 2012 09:50:26 -0500, Austin Clements amdra...@mit.edu wrote: The behavior of the header line in show-mode changed from showing the subject of the first open message to showing the subject of the first message in 4d77f18b. Update a comment to reflect this. Pushed. d ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
Re: [PATCH] man: document the notmuch configuration settings in notmuch-config(1)
On Sun, 26 Feb 2012 00:23:41 +0200, Jani Nikula j...@nikula.org wrote: At the risk of duplication between the man page and the configuration file generated by default, document the notmuch configuration options in the notmuch config man page. Pushed. d ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
Re: [PATCH] man: add references to maildir flag synchronization
On Sun, 26 Feb 2012 00:57:23 +0200, Jani Nikula j...@nikula.org wrote: notmuch new, restore, and tag commands support maildir flag synchronization with notmuch tags. Reference the notmuch-config(1) man page about it in the relevant man pages. Pushed d ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
