[PATCH] notmuch new --new-tags=tags...
Excerpts from Tomas Carnecky's message of Mon Apr 12 06:25:23 -0600 2010: > I have a patch which adds support for hooks which are run when tags are > added, removed or new messages added to notmuch. But perhaps the > fork/exec overhead of running the hooks would slow the processing down > too much. Rather than a fork/exec for every message, why not have a persistent subprocess that receives message IDs (+ filenames?) and can then do arbitrary work and return back the proper tags?
Re: [PATCH] notmuch new --new-tags=tags...
Excerpts from Tomas Carnecky's message of Mon Apr 12 06:25:23 -0600 2010: I have a patch which adds support for hooks which are run when tags are added, removed or new messages added to notmuch. But perhaps the fork/exec overhead of running the hooks would slow the processing down too much. Rather than a fork/exec for every message, why not have a persistent subprocess that receives message IDs (+ filenames?) and can then do arbitrary work and return back the proper tags? ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
[notmuch] [PATCH] Add an "--format=(json|text)" command-line option to both notmuch-search and notmuch-show.
Excerpts from David Bremner's message of Wed Feb 10 07:51:47 -0600 2010: > Dear Scott and other interested parties; > > As I play with json output a bit more, it seems like having > --entire-thread optional would be useful for quite a few applications. > For example, if I want to get the From address for a given message-ID, I > with the current setup I have to post process the output. This is > doable, but I wonder if the better option isn't to make --entire-thread > optional for --format=json as well. > > Any thoughts? I made --entire-thread forced becuase it kept the JSON patch minimal. The way the thread structure is calculated is closely tied into the message tree recursion. It would have required a much more significant refactoring to get both ways; and, I wanted the patch to have as few barriers to being merged. However, as patch still hasn't been merged and probably needs to be rebased, there doesn't seem to be any good reason anymore to avoid the work. Except, I can't do it. As I noted in an earlier e-mail, I have to abandon this piece of code. I'm a bit busy backpacking through Central America. :-)
[notmuch] Request for high-priority improvements to notmuch
Excerpts from sebastian's message of Mon Feb 01 14:29:44 -0600 2010: > 2) > > JSON output for "notmuch search/show" with ability to filter output fields > > "search" --> "search --output=thread_id,date,number,author,subject,tags" > > "show" --> "search > > --output=message_id,tags,path,header,body,attachments" > > YES PLEASE :-). notmuch seems designed to work in an ecosystem of > surrounding scripts, feeding data in and out. But we are all currently > limited to regexes for that. And heck, I hard a hard time understanding > why all hell broke out until I found that i had added a tag containing > parentheses which made my regex fail. :-). XML, JSON, any structured > output would be nice. > > And as for filtering: YES, PLEASE :-). notmuchsync and many other 3rd > party apps would love that. As father of notmuchsync, I can tell you my > little script hickups very badly when slurping in 200k mails (including > text bodies) just to find out the maildir tags of those mails. > There's been a JSON patch waiting for a month now.
[notmuch] tag dir proposal [was: Re: Git as notmuch object store]
Excerpts from Jameson Rollins's message of Mon Jan 25 15:46:55 -0600 2010: > I think this idea is a really good one and I would like to pursue it as > a tangent thread here. I was going to propose something very similar to > this. I think it's a very flexible idea that would help in a lot of > ways. > > [...] This is getting involved. Maybe I'm missing something in this thread; but, why couldn't these complex and context-sensitive decisions be delegated to sub-processes? ala git hooks?
Re: [notmuch] tag dir proposal [was: Re: Git as notmuch object store]
Excerpts from Jameson Rollins's message of Mon Jan 25 15:46:55 -0600 2010: I think this idea is a really good one and I would like to pursue it as a tangent thread here. I was going to propose something very similar to this. I think it's a very flexible idea that would help in a lot of ways. [...] This is getting involved. Maybe I'm missing something in this thread; but, why couldn't these complex and context-sensitive decisions be delegated to sub-processes? ala git hooks? ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
[notmuch] [PATCH] Build and link against notmuch shared library
Excerpts from bgamari.foss's message of Sat Jan 23 12:58:42 -0600 2010: > True, but I don't think that this means that we need to link the > executable with a C++ compiler. I've tried linking with CC and it seems > to succeed, so I don't think there should be a problem changing it. > Are you using "cc" or "gcc"? Even when cc is an alias to gcc, there are different semantics. And "cc" vs. "cpp" can be even more different on non-GCC compilers. I wouldn't mess with it. :-)
[notmuch] Idea for storing tags
I wrote a script to store and sync my tags. * One filename per message-ID. * Line-feed seperated tags in each file. Then the whole structure is controlled via git. Conflict-resolution and sync comes for free. It isn't clear what use-case the earlier e-mail is aiming to satisfy. This is how I solved my tag sync issues, though.
[notmuch] [PATCH] Add an "--format=(json|text)" command-line option to both notmuch-search and notmuch-show.
Excerpts from david's message of Thu Dec 31 07:17:40 -0800 2009: > I also changed the copyright of json.c to Scott. Hope that's OK with > Scott. That is totally OK. Thank you for carrying this patch to conclusion! Can't wait to see how notmuch has evolved in six or so months...
[notmuch] [PATCH] JSON output for notmuch-search and notmuch-show.
Excerpts from Carl Worth's message of Tue Dec 22 21:48:34 -0800 2009: > On Fri, 18 Dec 2009 10:47:33 -0800, Scott Robinson > wrote: > > Resubmit a full patch, or submit another one on top of it? > > A new full patch would be great, thanks! Sadly, I won't be able to make the changes requested. I'm falling off the Internet shortly. Hopefully David, who already put in a couple improvements, can do the finishing touches?
[notmuch] SWIG (and particularly Python) bindings
Excerpts from Adrian Perez de Castro's message of Wed Dec 30 02:52:23 -0800 2009: > BTW, I think that if more bindings start to appear, Notmuch might be built > as a shared library, to avoid duplicating it everywhere. One option may be > using *just* libtool but not the rest of auto-foo tools (for the record: > I agree with Carl that they are slow and wicked). http://github.com/quad/notmuch/tree/libtool -- Scott Robinson | http://quadhome.com/ Q: Why are my replies five sentences or less? A: http://five.sentenc.es/
Re: [notmuch] SWIG (and particularly Python) bindings
Excerpts from Adrian Perez de Castro's message of Wed Dec 30 02:52:23 -0800 2009: BTW, I think that if more bindings start to appear, Notmuch might be built as a shared library, to avoid duplicating it everywhere. One option may be using *just* libtool but not the rest of auto-foo tools (for the record: I agree with Carl that they are slow and wicked). http://github.com/quad/notmuch/tree/libtool -- Scott Robinson | http://quadhome.com/ Q: Why are my replies five sentences or less? A: http://five.sentenc.es/ ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
[notmuch] [PATCH] JSON output for notmuch-search and notmuch-show.
Excerpts from Carl Worth's message of Fri Dec 18 09:31:39 -0800 2009: > [...] > I don't know why, but I think I'd prefer --format for the name here. ACK > [...] > It looks like the new documentation is missing that point, (and the man > page in notmuch.1 is missing an update as well). ACK > [...] > That's just fine. The old numbering semantics were quite bizarre and > nothing I wanted to set it stone. Cool. :-) Resubmit a full patch, or submit another one on top of it? -- Scott Robinson | http://quadhome.com/ Q: Why are my replies five sentences or less? A: http://five.sentenc.es/
[notmuch] [PATCH] Add an "--output=(json|text|)" command-line option to both notmuch-search and notmuch-show.
Excerpts from Carl Worth's message of Fri Dec 18 09:33:43 -0800 2009: > On Fri, 18 Dec 2009 08:59:55 -0400, david at tethera.net wrote: > > It took me a little work to apply Scott's patch, so rather than asking > > him to resend it from git-send-email, I am just sending. I hope no-one > > is offended (much). > > I think that's great! Collaboration is what this is all about. Me too! I've never used git-send-email. I'll give it a whirl on my next patch. > > I'm thinking that the patch I sent out last night to only dump message > > ids could be reworked to use the framework of this patch. I also > > think it would be reasonably simple to add an --output=mbox option, > > for archiving and so on. > > I think that selecting *what* to emit is orthogonal from selecting *how* > to format that output. See some ideas in the TODO file, (where I > proposed --for and --format options for these). Having a way to do mbox > output for export would indeed be very nice. Haha! I originally used "--format" and changed for some reason that escapes me now. Implementing an "mbox" formatted output in the current logic wouldn't be archive perfect. The message body is emitted on a per-part basis. What I would do is change the semantics of format->body to be called from show_message. Then the text and json parts would point at the original implementation passing off their per-part function pointers. And, a new mbox implementation would just dump the full message body. -- Scott Robinson | http://quadhome.com/ Q: Why are my replies five sentences or less? A: http://five.sentenc.es/
[notmuch] [PATCH] JSON output for notmuch-search and notmuch-show.
i++;
break;
}
-if (strcmp(argv[i], "--entire-thread") == 0) {
+ if (STRNCMP_LITERAL (argv[i], "--output=") == 0) {
+ opt = argv[i] + sizeof ("--output=") - 1;
+ if (strcmp (opt, "text") == 0) {
+ format = _text;
+ } else if (strcmp (opt, "json") == 0) {
+ format = _json;
+ entire_thread = 1;
+ } else {
+ fprintf (stderr, "Invalid value for --output: %s\n", opt);
+ return 1;
+ }
+ } else if (STRNCMP_LITERAL (argv[i], "--entire-thread") == 0) {
entire_thread = 1;
} else {
fprintf (stderr, "Unrecognized option: %s\n", argv[i]);
@@ -268,6 +454,8 @@ notmuch_show_command (void *ctx, unused (int argc), unused
(char *argv[]))
return 1;
}
+fputs (format->message_set_start, stdout);
+
for (threads = notmuch_query_search_threads (query);
notmuch_threads_has_more (threads);
notmuch_threads_advance (threads))
@@ -280,11 +468,18 @@ notmuch_show_command (void *ctx, unused (int argc),
unused (char *argv[]))
INTERNAL_ERROR ("Thread %s has no toplevel messages.\n",
notmuch_thread_get_thread_id (thread));
- show_messages (ctx, messages, 0, entire_thread);
+ if (!first_toplevel)
+ fputs (format->message_set_sep, stdout);
+ first_toplevel = 0;
+
+ show_messages (ctx, format, messages, 0, entire_thread);
notmuch_thread_destroy (thread);
+
}
+fputs (format->message_set_end, stdout);
+
notmuch_query_destroy (query);
notmuch_database_close (notmuch);
diff --git a/notmuch.c b/notmuch.c
index 2ac8a59..aa2fc12 100644
--- a/notmuch.c
+++ b/notmuch.c
@@ -162,6 +162,11 @@ command_t commands[] = {
"\n"
"\t\tSupported options for search include:\n"
"\n"
+ "\t\t--output=(json|text)\n"
+ "\n"
+ "\t\t\tPresents the results in either JSON or plain-text\n"
+ "\t\t\tformat, which is the default.\n"
+ "\n"
"\t\t--sort=(newest-first|oldest-first)\n"
"\n"
"\t\t\tPresent results in either chronological order\n"
@@ -186,13 +191,18 @@ command_t commands[] = {
"\t\t\tall messages in the same thread as any matched\n"
"\t\t\tmessage will be displayed.\n"
"\n"
- "\t\tThe output format is plain-text, with all text-content\n"
- "\t\tMIME parts decoded. Various components in the output,\n"
- "\t\t('message', 'header', 'body', 'attachment', and MIME 'part')\n"
- "\t\tare delimited by easily-parsed markers. Each marker consists\n"
- "\t\tof a Control-L character (ASCII decimal 12), the name of\n"
- "\t\tthe marker, and then either an opening or closing brace,\n"
- "\t\t'{' or '}' to either open or close the component.\n"
+ "\t\t--output=(json|text)\n"
+ "\n"
+ "\t\t\tPresents the results in either JSON or plain-text\n"
+ "\t\t\tformat, which is the default.\n"
+ "\n"
+ "\t\tThe plain-text has all text-content MIME parts decoded.\n"
+ "\t\tVarious components in the output, ('message', 'header',\n"
+ "\t\t'body', 'attachment', and MIME 'part') are delimited by\n"
+ "\t\teasily-parsed markers. Each marker consists of a Control-L\n"
+ "\t\tcharacter (ASCII decimal 12), the name of the marker, and\n"
+ "\t\tthen either an opening or closing brace, '{' or '}' to\n"
+ "\t\teither open or close the component.\n"
"\n"
"\t\tA common use of \"notmuch show\" is to display a single\n"
"\t\tthread of email messages. For this, use a search term of\n"
diff --git a/show-message.c b/show-message.c
index 784981b..05ced9c 100644
--- a/show-message.c
+++ b/show-message.c
@@ -26,8 +26,6 @@ static void
show_message_part (GMimeObject *part, int *part_count,
void (*show_part) (GMimeObject *part, int *part_count))
{
-*part_count = *part_count + 1;
-
if (GMIME_IS_MULTIPART (part)) {
GMimeMultipart *multipart = GMIME_MULTIPART (part);
int i;
@@ -56,6 +54,8 @@ show_message_part (GMimeObject *part, int *part_count,
return;
}
+*part_count = *part_count + 1;
+
(*show_part) (part, part_count);
}
--
Scott Robinson | http://quadhome.com/
Q: Why are my replies five sentences or less?
A: http://five.sentenc.es/
[notmuch] [PATCH] JSON output for notmuch-search and notmuch-show.
commands[] = {
\n
\t\tSupported options for search include:\n
\n
+ \t\t--output=(json|text)\n
+ \n
+ \t\t\tPresents the results in either JSON or plain-text\n
+ \t\t\tformat, which is the default.\n
+ \n
\t\t--sort=(newest-first|oldest-first)\n
\n
\t\t\tPresent results in either chronological order\n
@@ -186,13 +191,18 @@ command_t commands[] = {
\t\t\tall messages in the same thread as any matched\n
\t\t\tmessage will be displayed.\n
\n
- \t\tThe output format is plain-text, with all text-content\n
- \t\tMIME parts decoded. Various components in the output,\n
- \t\t('message', 'header', 'body', 'attachment', and MIME 'part')\n
- \t\tare delimited by easily-parsed markers. Each marker consists\n
- \t\tof a Control-L character (ASCII decimal 12), the name of\n
- \t\tthe marker, and then either an opening or closing brace,\n
- \t\t'{' or '}' to either open or close the component.\n
+ \t\t--output=(json|text)\n
+ \n
+ \t\t\tPresents the results in either JSON or plain-text\n
+ \t\t\tformat, which is the default.\n
+ \n
+ \t\tThe plain-text has all text-content MIME parts decoded.\n
+ \t\tVarious components in the output, ('message', 'header',\n
+ \t\t'body', 'attachment', and MIME 'part') are delimited by\n
+ \t\teasily-parsed markers. Each marker consists of a Control-L\n
+ \t\tcharacter (ASCII decimal 12), the name of the marker, and\n
+ \t\tthen either an opening or closing brace, '{' or '}' to\n
+ \t\teither open or close the component.\n
\n
\t\tA common use of \notmuch show\ is to display a single\n
\t\tthread of email messages. For this, use a search term of\n
diff --git a/show-message.c b/show-message.c
index 784981b..05ced9c 100644
--- a/show-message.c
+++ b/show-message.c
@@ -26,8 +26,6 @@ static void
show_message_part (GMimeObject *part, int *part_count,
void (*show_part) (GMimeObject *part, int *part_count))
{
-*part_count = *part_count + 1;
-
if (GMIME_IS_MULTIPART (part)) {
GMimeMultipart *multipart = GMIME_MULTIPART (part);
int i;
@@ -56,6 +54,8 @@ show_message_part (GMimeObject *part, int *part_count,
return;
}
+*part_count = *part_count + 1;
+
(*show_part) (part, part_count);
}
--
Scott Robinson | http://quadhome.com/
Q: Why are my replies five sentences or less?
A: http://five.sentenc.es/
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch
[notmuch] RFC: output json from notmuch?
Excerpts from David Bremner's message of Sun Dec 13 15:26:02 -0800 2009: > On Sun, 13 Dec 2009 19:21:02 -0400, David Bremner > wrote: > > > > Attachments: json output of a message from carl, and the equivalent > > sexpr as parsed by json.el. > > > uh, right. Second time lucky. > I have a patch for a --output=(text|json) for both notmuch-show and notmuch-search. I mentioned it earlier on the list, and no one seemed to have any interest. Is it worth updating to HEAD and trying again? -- Scott Robinson | http://quadhome.com/ Q: Why are my replies five sentences or less? A: http://five.sentenc.es/
Re: [notmuch] RFC: output json from notmuch?
Excerpts from David Bremner's message of Sun Dec 13 15:26:02 -0800 2009: On Sun, 13 Dec 2009 19:21:02 -0400, David Bremner da...@tethera.net wrote: Attachments: json output of a message from carl, and the equivalent sexpr as parsed by json.el. uh, right. Second time lucky. I have a patch for a --output=(text|json) for both notmuch-show and notmuch-search. I mentioned it earlier on the list, and no one seemed to have any interest. Is it worth updating to HEAD and trying again? -- Scott Robinson | http://quadhome.com/ Q: Why are my replies five sentences or less? A: http://five.sentenc.es/ ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
[notmuch] [PATCH] notmuch-restore.c: only update tags for messages that differ from dump file.
Excerpts from david's message of Mon Dec 07 19:14:48 -0800 2009: > The patch allocates a temporary array to keep track of the current > list of tags using calloc and grows it as neccesary using realloc. The codebase has already well established the use of the talloc library. Why did you break with that? -- Scott Robinson | http://quadhome.com/ Q: Why are my replies five sentences or less? A: http://five.sentenc.es/
Re: [notmuch] [PATCH] notmuch-restore.c: only update tags for messages that differ from dump file.
Excerpts from david's message of Mon Dec 07 19:14:48 -0800 2009: The patch allocates a temporary array to keep track of the current list of tags using calloc and grows it as neccesary using realloc. The codebase has already well established the use of the talloc library. Why did you break with that? -- Scott Robinson | http://quadhome.com/ Q: Why are my replies five sentences or less? A: http://five.sentenc.es/ ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
[notmuch] Using notmuch from Ruby, Python, et al.
Excerpts from Jeffrey Ollie's message of Wed Nov 25 10:03:05 -0800 2009: > On Wed, Nov 25, 2009 at 11:58 AM, Scott Robinson > wrote: > > Would it be better to link with a previously existing library? > > IMHO yes. I was looking at json-glib because it seems to be the only > C JSON API in Fedora, plus it's based upon glib. From what I've read > it should be really easy to serialize a GMimeObject to a JSON > structure with very few calls using json-glib. I'm taking a look at json-glib now. But, it doesn't look to support streaming output. -- Scott Robinson | http://quadhome.com/ Q: Why are my replies five sentences or less? A: http://five.sentenc.es/
[notmuch] Using notmuch from Ruby, Python, et al.
Excerpts from Jeffrey Ollie's message of Wed Nov 25 09:46:47 -0800 2009: > On Wed, Nov 25, 2009 at 10:16 AM, Scott Robinson > wrote: > > > > To accomplish this, I used the cJSON library sans parsing logic. > > I wasn't familiar with cJSON so I went over to take a look. I haven't > really examined the code, but I really don't like the fact that you > are expected to copy the cJSON code into your project. I selected cJSON because it was simple for integration. Given how libsha1.c is included in lib/, I figured adding a depedency wouldn't be very popular. Would it be better to link with a previously existing library? -- Scott Robinson | http://quadhome.com/ Q: Why are my replies five sentences or less? A: http://five.sentenc.es/
[notmuch] Using notmuch from Ruby, Python, et al.
Excerpts from Jeffrey Ollie's message of Wed Nov 25 08:33:39 -0800 2009: > On Wed, Nov 25, 2009 at 10:16 AM, Scott Robinson > wrote: > > > > == Shared Library > > > > I have modified the build to output a shared library. It's a small change > > relying on libtool. > > > > However, the archives indicate Carl dislikes libtool? > > Ugh, please, let's not go down the autoconf/automake/libtool route. I didn't use autoconf and friends. Just put in libtool where $(CXX) and $(CC) are. Going with the system defaults. See the attached patch. > > == JSON output > > > > I added a --output=(text|json) option to "search" and "show." Then, emit > > json > > results appropriately. > > > > To accomplish this, I used the cJSON library sans parsing logic. > > > > However, I saw discussion about providing a --format option? > > Awesome, I was just looking at using json-glib but I haven't gotten > very far yet, mainly because I've never used it before (nor done much > of anything with JSON). I was going to call the option > '--output-format=(standard|json)' but I'm not going to worry about the > color of that bikeshed. > > IMHO, I think both approaches would be valuable, that way people > writing front ends could choose the methods that worked best for them. > Do you have patches that you are ready to share? > Yes! As the json work is a bit more substantial, is it preferable to start a [PATCH] thread or link to a git repo? -- Scott Robinson | http://quadhome.com/ Q: Why are my replies five sentences or less? A: http://five.sentenc.es/ -- next part -- A non-text attachment was scrubbed... Name: libtoolize-notmuch.diff Type: application/octet-stream Size: 3996 bytes Desc: not available URL: <http://notmuchmail.org/pipermail/notmuch/attachments/20091125/7d8741a7/attachment.obj>
[notmuch] Using notmuch from Ruby, Python, et al.
I'm hoping this thread will provide a guide for my efforts. I'm writing a web frontend for notmuch in Ruby. But, the output from the notmuch command-line is ambiguous. Therefore, I've started two branches experimenting with different ways of providing hooks. Which of these approaches are likely to be pulled upstream? == Shared Library I have modified the build to output a shared library. It's a small change relying on libtool. However, the archives indicate Carl dislikes libtool? == JSON output I added a --output=(text|json) option to "search" and "show." Then, emit json results appropriately. To accomplish this, I used the cJSON library sans parsing logic. However, I saw discussion about providing a --format option? -- Scott Robinson | http://quadhome.com/ Q: Why are my replies five sentences or less? A: http://five.sentenc.es/
