output file argument to notmuch dump.
On Fri, 07 Oct 2011 04:37:56 +0400, Dmitry Kurochkin wrote: > On Thu, 06 Oct 2011 21:20:40 -0300, David Bremner wrote: > IMHO 1[+2] is the way. It breaks the dump command interface, but would > make it consistent with other commands. Implementing the second option > (for all commands) is nice but independent and optional. Also, perhaps > --output, --output-file or smth would a better name than --write. I'm not fussy about the name, except that --output is taken, and I thought there might be some benefit of making options have unique prefixes. d -- next part -- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 315 bytes Desc: not available URL: <http://notmuchmail.org/pipermail/notmuch/attachments/20111006/74ecff59/attachment.pgp>
output file argument to notmuch dump.
On Thu, 06 Oct 2011 21:53:57 -0300, David Bremner wrote: > On Fri, 07 Oct 2011 04:37:56 +0400, Dmitry Kurochkin gmail.com> wrote: > > On Thu, 06 Oct 2011 21:20:40 -0300, David Bremner wrote: > > > IMHO 1[+2] is the way. It breaks the dump command interface, but would > > make it consistent with other commands. Implementing the second option > > (for all commands) is nice but independent and optional. Also, perhaps > > --output, --output-file or smth would a better name than --write. > > I'm not fussy about the name, except that --output is taken, and I > thought there might be some benefit of making options have unique > prefixes. Is -o/--output taken before the subcommand? i.e. notmuch -o dump Or would that be to confusing? (-o is fairly standard for stdout redirection, so it would be nice to use that for notmuch, as well.) Tom
output file argument to notmuch dump.
I'd like to add a search term argument to notmuch dump (see id:"87wrcijn1w.fsf at zancas.localnet" and followup for context). The "notmuch" way would be to have notmuch dump do the right thing, and that is easy enough _except_ that notmuch dump foo writes the output to file foo. I see several options. 1) just delete the output file option from notmuch-dump, and use shell redirection. So far I don't see a non-contrived example when writing an output file directly is useful, but maybe that is just a failure of imagination. 2) delete the output file option and a global "--write" option that calls freopen(... stdout). As a bonus(?) this would work for any notmuch command. 3) leave the output option alone and implement a --query=foo option for notmuch dump. This would be the most backward compatible of course, but also confusing for users. Thoughts? d -- next part -- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 315 bytes Desc: not available URL: <http://notmuchmail.org/pipermail/notmuch/attachments/20111006/2284f4dd/attachment.pgp>
tag sharing
On Thu, 06 Oct 2011 16:40:00 -0400, Jesse Rosenthal
wrote:
> On Thu, 06 Oct 2011 17:23:21 -0300, David Bremner
> wrote:
> > What doesn't work is searches for the whole namespace "notmuch search
> > tag:bremner.*" will return nothing, even though "notmuch search
> > tag:bremner.to-fix" does.
>
> A simple shell way to do this would be
>
> notmuch search-tags | grep "^bremner\." | xargs -I {} notmuch search
> tag:{}
>
Ah thanks, that is not so bad. It turns out to be literally a one line
change to add a query argument for notmuch-dump, _except_ that notmuch
dump already uses the first command line argument as an output file
name. I think I will start a seperate thread about that. If you want to
test, this works OK, except the output is put in a file named after the
query ;).
diff --git a/notmuch-dump.c b/notmuch-dump.c
index 7e7bc17..341207a 100644
--- a/notmuch-dump.c
+++ b/notmuch-dump.c
@@ -40,7 +40,7 @@ notmuch_dump_command (unused (void *ctx), int argc, char
*argv[])
if (notmuch == NULL)
return 1;
-query = notmuch_query_create (notmuch, "");
+query = notmuch_query_create (notmuch, argc > 0 ? argv[0] : "");
if (query == NULL) {
fprintf (stderr, "Out of memory\n");
return 1;
Re: output file argument to notmuch dump.
On Thu, 06 Oct 2011 21:53:57 -0300, David Bremner wrote: > On Fri, 07 Oct 2011 04:37:56 +0400, Dmitry Kurochkin > wrote: > > On Thu, 06 Oct 2011 21:20:40 -0300, David Bremner wrote: > > > IMHO 1[+2] is the way. It breaks the dump command interface, but would > > make it consistent with other commands. Implementing the second option > > (for all commands) is nice but independent and optional. Also, perhaps > > --output, --output-file or smth would a better name than --write. > > I'm not fussy about the name, except that --output is taken, and I > thought there might be some benefit of making options have unique > prefixes. Is -o/--output taken before the subcommand? i.e. notmuch -o dump Or would that be to confusing? (-o is fairly standard for stdout redirection, so it would be nice to use that for notmuch, as well.) Tom ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
Re: output file argument to notmuch dump.
On Thu, 06 Oct 2011 21:20:40 -0300, David Bremner wrote: > I see several options. > > 1) just delete the output file option from notmuch-dump, and use shell >redirection. So far I don't see a non-contrived example when writing >an output file directly is useful, but maybe that is just a failure >of imagination. > > 2) delete the output file option and a global "--write" option that >calls freopen(... stdout). As a bonus(?) this would work for any >notmuch command. I strongly support either of these two options (they're basically the same as far as I'm concerned). The consistency that this would provide with rest of the notmuch commands alone kind of makes this a no-brainer in my opinion. And I certainly don't see this particular CLI breakage as an issue either. jamie. pgpwMNtCDrJbk.pgp Description: PGP signature ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
output file argument to notmuch dump.
On Thu, 06 Oct 2011 21:20:40 -0300, David Bremner wrote: > I see several options. > > 1) just delete the output file option from notmuch-dump, and use shell >redirection. So far I don't see a non-contrived example when writing >an output file directly is useful, but maybe that is just a failure >of imagination. > > 2) delete the output file option and a global "--write" option that >calls freopen(... stdout). As a bonus(?) this would work for any >notmuch command. I strongly support either of these two options (they're basically the same as far as I'm concerned). The consistency that this would provide with rest of the notmuch commands alone kind of makes this a no-brainer in my opinion. And I certainly don't see this particular CLI breakage as an issue either. jamie. -- next part -- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 835 bytes Desc: not available URL: <http://notmuchmail.org/pipermail/notmuch/attachments/20111006/fb867451/attachment-0001.pgp>
Re: output file argument to notmuch dump.
On Fri, 07 Oct 2011 04:37:56 +0400, Dmitry Kurochkin wrote: > On Thu, 06 Oct 2011 21:20:40 -0300, David Bremner wrote: > IMHO 1[+2] is the way. It breaks the dump command interface, but would > make it consistent with other commands. Implementing the second option > (for all commands) is nice but independent and optional. Also, perhaps > --output, --output-file or smth would a better name than --write. I'm not fussy about the name, except that --output is taken, and I thought there might be some benefit of making options have unique prefixes. d pgpZ0QAwIdijG.pgp Description: PGP signature ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
[RFC/PATCH] notmuch link
On Tue 04 Oct 2011 00:15, Ali Polatel writes: > Ali Polatel yazm??: >> >>This mail is merely a request for comments and testing. > > Sigh... > I have just noticed "notmuch show" learned --format=mbox which makes > this patch rather pointless for me. This changeset will keep living > under my notmuch repository possibly without receiving any updates. > >>Ali Polatel (1): >> link: Add new command The 'link' feature would have been pretty cool as the linking goes blazingly fast. But, the unfortunate side effect of this would be that if the file referenced by link is modified, the original file gets modified.I personally don't want this to happen after the mail is delivered unless I intentionally do it (my delivered mails filenames are generated from the md5sum of the original content, so re-comparing all content will reveal what files been modified :D) If one of the goals of notmuch is to not to change the contents of mail files and avoid this happening accidentally by other programs (referencing files in configured 'path' from other programs considered non-accidental action) then this feature should just be dropped (but not forgotten so it doesn't get re-implemented). > -alip Tomi
Re: output file argument to notmuch dump.
On Thu, 06 Oct 2011 21:20:40 -0300, David Bremner wrote: > > I'd like to add a search term argument to notmuch dump (see > id:"87wrcijn1w.fsf@zancas.localnet" and followup for context). The > "notmuch" way would be to have > > notmuch dump > > do the right thing, and that is easy enough _except_ that > >notmuch dump foo > > writes the output to file foo. > > I see several options. > > 1) just delete the output file option from notmuch-dump, and use shell >redirection. So far I don't see a non-contrived example when writing >an output file directly is useful, but maybe that is just a failure >of imagination. > > 2) delete the output file option and a global "--write" option that >calls freopen(... stdout). As a bonus(?) this would work for any >notmuch command. > > 3) leave the output option alone and implement a --query=foo option for >notmuch dump. This would be the most backward compatible of course, >but also confusing for users. > > Thoughts? > IMHO 1[+2] is the way. It breaks the dump command interface, but would make it consistent with other commands. Implementing the second option (for all commands) is nice but independent and optional. Also, perhaps --output, --output-file or smth would a better name than --write. Regards, Dmitry > d > > > ___ > notmuch mailing list > notmuch@notmuchmail.org > http://notmuchmail.org/mailman/listinfo/notmuch ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
output file argument to notmuch dump.
I'd like to add a search term argument to notmuch dump (see id:"87wrcijn1w.fsf@zancas.localnet" and followup for context). The "notmuch" way would be to have notmuch dump do the right thing, and that is easy enough _except_ that notmuch dump foo writes the output to file foo. I see several options. 1) just delete the output file option from notmuch-dump, and use shell redirection. So far I don't see a non-contrived example when writing an output file directly is useful, but maybe that is just a failure of imagination. 2) delete the output file option and a global "--write" option that calls freopen(... stdout). As a bonus(?) this would work for any notmuch command. 3) leave the output option alone and implement a --query=foo option for notmuch dump. This would be the most backward compatible of course, but also confusing for users. Thoughts? d pgpuDZkirzU7W.pgp Description: PGP signature ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
tag sharing
On Thu, 06 Oct 2011 15:49:10 -0400, Jesse Rosenthal wrote: > > A period works: `tag:bremner.to-fix`. That would fit with java/python > conventions. Double-colons also seem to work, for what it's worth: > `tag:bremner::to-fix` Right, I was confused and/or unclear. What doesn't work is searches for the whole namespace "notmuch search tag:bremner.*" will return nothing, even though "notmuch search tag:bremner.to-fix" does. d
Re: tag sharing
On Thu, 06 Oct 2011 16:40:00 -0400, Jesse Rosenthal wrote:
> On Thu, 06 Oct 2011 17:23:21 -0300, David Bremner wrote:
> > What doesn't work is searches for the whole namespace "notmuch search
> > tag:bremner.*" will return nothing, even though "notmuch search
> > tag:bremner.to-fix" does.
>
> A simple shell way to do this would be
>
> notmuch search-tags | grep "^bremner\." | xargs -I {} notmuch search
> tag:{}
>
Ah thanks, that is not so bad. It turns out to be literally a one line
change to add a query argument for notmuch-dump, _except_ that notmuch
dump already uses the first command line argument as an output file
name. I think I will start a seperate thread about that. If you want to
test, this works OK, except the output is put in a file named after the
query ;).
diff --git a/notmuch-dump.c b/notmuch-dump.c
index 7e7bc17..341207a 100644
--- a/notmuch-dump.c
+++ b/notmuch-dump.c
@@ -40,7 +40,7 @@ notmuch_dump_command (unused (void *ctx), int argc, char
*argv[])
if (notmuch == NULL)
return 1;
-query = notmuch_query_create (notmuch, "");
+query = notmuch_query_create (notmuch, argc > 0 ? argv[0] : "");
if (query == NULL) {
fprintf (stderr, "Out of memory\n");
return 1;
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch
tag sharing
On Thu, 06 Oct 2011 17:23:21 -0300, David Bremner wrote:
> What doesn't work is searches for the whole namespace "notmuch search
> tag:bremner.*" will return nothing, even though "notmuch search
> tag:bremner.to-fix" does.
A simple shell way to do this would be
notmuch search-tags | grep "^bremner\." | xargs -I {} notmuch search tag:{}
That's pretty quick over a fair amount of messages. It would be quicker,
I imagine, if it did the grepping inside of a program, but this is still
way down there in the subsecond range.
NB. I don't have that many tags, so maybe the grepping step would bog
down a bit if I had more. But I doubt someone would have that much more
than a few hundred.
tag sharing
On Thu, 06 Oct 2011 11:18:51 -0300, David Bremner wrote: > something like that sounds plausible. Currently the query parser doesn't > handle searches like "tag:bremner/to-fix" very well, because it > helpfully splits at '/' (aiui; maybe somebody else can explain it > better). "notmuch search "tag:notmuch*" does not seem to work either, > so my first idea to kludge around the problem by using > e.g. "notmuchPushed" doesn't seem to work either. A period works: `tag:bremner.to-fix`. That would fit with java/python conventions. Double-colons also seem to work, for what it's worth: `tag:bremner::to-fix`
Re: tag sharing
On Thu, 06 Oct 2011 17:23:21 -0300, David Bremner wrote:
> What doesn't work is searches for the whole namespace "notmuch search
> tag:bremner.*" will return nothing, even though "notmuch search
> tag:bremner.to-fix" does.
A simple shell way to do this would be
notmuch search-tags | grep "^bremner\." | xargs -I {} notmuch search tag:{}
That's pretty quick over a fair amount of messages. It would be quicker,
I imagine, if it did the grepping inside of a program, but this is still
way down there in the subsecond range.
NB. I don't have that many tags, so maybe the grepping step would bog
down a bit if I had more. But I doubt someone would have that much more
than a few hundred.
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch
Re: tag sharing
On Thu, 06 Oct 2011 15:49:10 -0400, Jesse Rosenthal wrote: > > A period works: `tag:bremner.to-fix`. That would fit with java/python > conventions. Double-colons also seem to work, for what it's worth: > `tag:bremner::to-fix` Right, I was confused and/or unclear. What doesn't work is searches for the whole namespace "notmuch search tag:bremner.*" will return nothing, even though "notmuch search tag:bremner.to-fix" does. d ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
Re: tag sharing
On Thu, 06 Oct 2011 11:18:51 -0300, David Bremner wrote: > something like that sounds plausible. Currently the query parser doesn't > handle searches like "tag:bremner/to-fix" very well, because it > helpfully splits at '/' (aiui; maybe somebody else can explain it > better). "notmuch search "tag:notmuch*" does not seem to work either, > so my first idea to kludge around the problem by using > e.g. "notmuchPushed" doesn't seem to work either. A period works: `tag:bremner.to-fix`. That would fit with java/python conventions. Double-colons also seem to work, for what it's worth: `tag:bremner::to-fix` ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
tag sharing
On Thu, 06 Oct 2011 09:21:48 -0400, Jesse Rosenthal wrote: > morning's project. In retrospect, I think the main issue was that I was > trying to figure out how history would be kept. By using git, though, > your idea would be that we get history for free, right? Yeah. Of course, one would have to decide if the history of the current dump file format is intelligible, or if some alternative format should be used. > of git? I.e., all we need something to just keep different dumps in > different namespaces, so that when I pull your dump, the tags come in as > `bremner/to-fix` (or whatever our separator is), and then when I dump > all `bremner` tags, it removes the namespace and puts it in > `bremner.tagfile`. something like that sounds plausible. Currently the query parser doesn't handle searches like "tag:bremner/to-fix" very well, because it helpfully splits at '/' (aiui; maybe somebody else can explain it better). "notmuch search "tag:notmuch*" does not seem to work either, so my first idea to kludge around the problem by using e.g. "notmuchPushed" doesn't seem to work either. > So using > either the library or the bindings would probably speed things up quite > a bit, by only dumping the tags you care about. Which means it couldn't > just be a shell script: it would have to be c/ruby/python. Without looking at the code, I'd guess it wouldn't be too hard to have notmuch-dump take a standard search term; it's just as I mentioned I don't see an elegant way of doing what we want with a standard search term. Of course I'd be happy to be proved wrong. David -- next part -- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 315 bytes Desc: not available URL: <http://notmuchmail.org/pipermail/notmuch/attachments/20111006/a4f5c700/attachment.pgp>
[PATCH 1/2] emacs: add notmuch-show-refresh-view function
On Sat, 28 May 2011 17:09:43 -0700, Jameson Graef Rollins wrote: > This function, like the equivalent for notmuch-search, just refreshes > the current show view. Like in notmuch-search, this new function is > bound to "=". If a prefix is given then the rediplay happens with the > crypto-switch set, which displays the thread with the opposite logic > of whatever is set in the notmuch-crypto-process-mime customization > variable. Pushed to master. Again, it would be nice to have tests for this. In fact this the patch I meant to attach that remark to; the hooks that invoke gpg and network access sound pretty tricky to test. David
Re: [PATCH 1/2] emacs: add notmuch-show-refresh-view function
On Thu, 06 Oct 2011 10:35:14 -0300, David Bremner wrote: > Applied to master, will push. Eventually it would be nice to have a test > for this, if possible. Thanks, David. I'll work on a test. jamie. ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
[PATCH 1/2] emacs: add notmuch-show-refresh-view function
On Thu, 06 Oct 2011 10:35:14 -0300, David Bremner wrote: > Applied to master, will push. Eventually it would be nice to have a test > for this, if possible. Thanks, David. I'll work on a test. jamie.
[PATCH 1/2] emacs: add notmuch-show-refresh-view function
On Sat, 28 May 2011 17:09:43 -0700, Jameson Graef Rollins wrote: > This function, like the equivalent for notmuch-search, just refreshes > the current show view. Like in notmuch-search, this new function is > bound to "=". If a prefix is given then the rediplay happens with the > crypto-switch set, which displays the thread with the opposite logic > of whatever is set in the notmuch-crypto-process-mime customization > variable. Applied to master, will push. Eventually it would be nice to have a test for this, if possible. d
tweaks for handling parts in reply
On Wed, 8 Jun 2011 12:30:05 -0700, Jameson Graef Rollins wrote: > This is a small set of tweaks to remove unneccessary "Non-text part:" > lines in reply, for parts that really don't need to be mentioned. I have applied this series on top of master, and will push a bit later today. d
Re: tweaks for handling parts in reply
On Thu, 06 Oct 2011 10:29:52 -0300, David Bremner wrote: > I have applied this series on top of master, and will push a bit later today. Great. Thanks so much, David. jamie. ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
tweaks for handling parts in reply
On Thu, 06 Oct 2011 10:29:52 -0300, David Bremner wrote: > I have applied this series on top of master, and will push a bit later today. Great. Thanks so much, David. jamie.
tag sharing
On Wed, 08 Jun 2011 10:46:57 -0700, Jameson Graef Rollins wrote: > On Mon, 06 Jun 2011 13:20:00 -0400, Jesse Rosenthal > wrote: > > After a conversation with David last year about bug-tracking, I worked > > up a rough python-based prototype of this. It worked in terms of > > namespaces, so Carl could associate the namespace "public" with a list > > of tags he publishes to a http-accessable location. And you could > > associate the namespace "cworth" with those same tags. > > This sounds very cool, Jesse. Very git-like. I like it. > Warning: git fanboi-ism ahead. I like the concept too. But I worry a bit that we are re-inventing things that could be done by git. What do people think about a similar namespace import export tool where we rely on git for a transport layer, and for merging, conflict-resolution, and history tracking. Of course there are details to be settled, but before I try to work them out, would anyone like to convince me the idea is fundementally wrong headed? Jesse, do you remember why you decided to roll your own? I agree it is subjective what is easier, but I think we have enough people comfortable with git that collaborative maintenence of a bug-tag git repo would be pretty easy. d
tag sharing
On Thu, 06 Oct 2011 09:56:43 -0300, David Bremner wrote: > Jesse, do you remember why you decided to roll your own? Only reason I can remember (a year and a half later) of is that it seemed like the basic illustration of concept would be a saturday morning's project. In retrospect, I think the main issue was that I was trying to figure out how history would be kept. By using git, though, your idea would be that we get history for free, right? I think my format was: 12345 foo at barto-fix 13456 bar at foofeature-request But using git would get us timestamps for free too, I guess. And if we get rid of timestamps, then we just have dumps. So what we would really just need is a thin namespacing layer in some scripting language on top of git? I.e., all we need something to just keep different dumps in different namespaces, so that when I pull your dump, the tags come in as `bremner/to-fix` (or whatever our separator is), and then when I dump all `bremner` tags, it removes the namespace and puts it in `bremner.tagfile`. One rather obvious thing that I discovered: processing dumps and restores from the ui is pretty slow, because you have to output a huge file, and then find the tags in your preferred namespace. So using either the library or the bindings would probably speed things up quite a bit, by only dumping the tags you care about. Which means it couldn't just be a shell script: it would have to be c/ruby/python. Best, Jesse
Re: [RFC/PATCH] notmuch link
On Tue 04 Oct 2011 00:15, Ali Polatel writes: > Ali Polatel yazmış: >> >>This mail is merely a request for comments and testing. > > Sigh... > I have just noticed "notmuch show" learned --format=mbox which makes > this patch rather pointless for me. This changeset will keep living > under my notmuch repository possibly without receiving any updates. > >>Ali Polatel (1): >> link: Add new command The 'link' feature would have been pretty cool as the linking goes blazingly fast. But, the unfortunate side effect of this would be that if the file referenced by link is modified, the original file gets modified.I personally don't want this to happen after the mail is delivered unless I intentionally do it (my delivered mails filenames are generated from the md5sum of the original content, so re-comparing all content will reveal what files been modified :D) If one of the goals of notmuch is to not to change the contents of mail files and avoid this happening accidentally by other programs (referencing files in configured 'path' from other programs considered non-accidental action) then this feature should just be dropped (but not forgotten so it doesn't get re-implemented). > -alip Tomi ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
Re: tag sharing
On Thu, 06 Oct 2011 09:56:43 -0300, David Bremner wrote: > Jesse, do you remember why you decided to roll your own? Only reason I can remember (a year and a half later) of is that it seemed like the basic illustration of concept would be a saturday morning's project. In retrospect, I think the main issue was that I was trying to figure out how history would be kept. By using git, though, your idea would be that we get history for free, right? I think my format was: 12345 foo@barto-fix 13456 bar@foofeature-request But using git would get us timestamps for free too, I guess. And if we get rid of timestamps, then we just have dumps. So what we would really just need is a thin namespacing layer in some scripting language on top of git? I.e., all we need something to just keep different dumps in different namespaces, so that when I pull your dump, the tags come in as `bremner/to-fix` (or whatever our separator is), and then when I dump all `bremner` tags, it removes the namespace and puts it in `bremner.tagfile`. One rather obvious thing that I discovered: processing dumps and restores from the ui is pretty slow, because you have to output a huge file, and then find the tags in your preferred namespace. So using either the library or the bindings would probably speed things up quite a bit, by only dumping the tags you care about. Which means it couldn't just be a shell script: it would have to be c/ruby/python. Best, Jesse ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
Re: tag sharing
On Thu, 06 Oct 2011 09:21:48 -0400, Jesse Rosenthal wrote: > morning's project. In retrospect, I think the main issue was that I was > trying to figure out how history would be kept. By using git, though, > your idea would be that we get history for free, right? Yeah. Of course, one would have to decide if the history of the current dump file format is intelligible, or if some alternative format should be used. > of git? I.e., all we need something to just keep different dumps in > different namespaces, so that when I pull your dump, the tags come in as > `bremner/to-fix` (or whatever our separator is), and then when I dump > all `bremner` tags, it removes the namespace and puts it in > `bremner.tagfile`. something like that sounds plausible. Currently the query parser doesn't handle searches like "tag:bremner/to-fix" very well, because it helpfully splits at '/' (aiui; maybe somebody else can explain it better). "notmuch search "tag:notmuch*" does not seem to work either, so my first idea to kludge around the problem by using e.g. "notmuchPushed" doesn't seem to work either. > So using > either the library or the bindings would probably speed things up quite > a bit, by only dumping the tags you care about. Which means it couldn't > just be a shell script: it would have to be c/ruby/python. Without looking at the code, I'd guess it wouldn't be too hard to have notmuch-dump take a standard search term; it's just as I mentioned I don't see an elegant way of doing what we want with a standard search term. Of course I'd be happy to be proved wrong. David pgprd6P3nNjJz.pgp Description: PGP signature ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
Re: [PATCH 1/2] emacs: add notmuch-show-refresh-view function
On Sat, 28 May 2011 17:09:43 -0700, Jameson Graef Rollins wrote: > This function, like the equivalent for notmuch-search, just refreshes > the current show view. Like in notmuch-search, this new function is > bound to "=". If a prefix is given then the rediplay happens with the > crypto-switch set, which displays the thread with the opposite logic > of whatever is set in the notmuch-crypto-process-mime customization > variable. Pushed to master. Again, it would be nice to have tests for this. In fact this the patch I meant to attach that remark to; the hooks that invoke gpg and network access sound pretty tricky to test. David ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
Re: [PATCH 1/2] emacs: add notmuch-show-refresh-view function
On Sat, 28 May 2011 17:09:43 -0700, Jameson Graef Rollins wrote: > This function, like the equivalent for notmuch-search, just refreshes > the current show view. Like in notmuch-search, this new function is > bound to "=". If a prefix is given then the rediplay happens with the > crypto-switch set, which displays the thread with the opposite logic > of whatever is set in the notmuch-crypto-process-mime customization > variable. Applied to master, will push. Eventually it would be nice to have a test for this, if possible. d ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
Re: tweaks for handling parts in reply
On Wed, 8 Jun 2011 12:30:05 -0700, Jameson Graef Rollins wrote: > This is a small set of tweaks to remove unneccessary "Non-text part:" > lines in reply, for parts that really don't need to be mentioned. I have applied this series on top of master, and will push a bit later today. d ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
Re: tag sharing
On Wed, 08 Jun 2011 10:46:57 -0700, Jameson Graef Rollins wrote: > On Mon, 06 Jun 2011 13:20:00 -0400, Jesse Rosenthal > wrote: > > After a conversation with David last year about bug-tracking, I worked > > up a rough python-based prototype of this. It worked in terms of > > namespaces, so Carl could associate the namespace "public" with a list > > of tags he publishes to a http-accessable location. And you could > > associate the namespace "cworth" with those same tags. > > This sounds very cool, Jesse. Very git-like. I like it. > Warning: git fanboi-ism ahead. I like the concept too. But I worry a bit that we are re-inventing things that could be done by git. What do people think about a similar namespace import export tool where we rely on git for a transport layer, and for merging, conflict-resolution, and history tracking. Of course there are details to be settled, but before I try to work them out, would anyone like to convince me the idea is fundementally wrong headed? Jesse, do you remember why you decided to roll your own? I agree it is subjective what is easier, but I think we have enough people comfortable with git that collaborative maintenence of a bug-tag git repo would be pretty easy. d ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
Re: [python] can't find shared lib
On Wed, 05 Oct 2011 13:58:14 +0100, Patrick Totzke wrote: > I fumbled around with resetting come commits, and it turns out that the > problem is in 9e976fc60c40e07cb62a7d656e86ee3101c1b2f5. Once resetted before > that, > everything works nicely. Thanks for the pointer :) [master 7047975] python: also use libnotmuch.so.2 Sebastian pgpBkE4vUdBAM.pgp Description: PGP signature ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
Re: [PATCH] lib: make find_message{,by_filename) report errors
The new API looks sane and much better to me. +1, just give me plenty of time to catch up before releasing once this goes in :-) Sebastian pgpnZQGJSMlVt.pgp Description: PGP signature ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
