output file argument to notmuch dump.

2011-10-06 Thread David Bremner
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.

2011-10-06 Thread Tom Prince
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.

2011-10-06 Thread David Bremner

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

2011-10-06 Thread David Bremner
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;


output file argument to notmuch dump.

2011-10-06 Thread Jameson Graef Rollins
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>


[RFC/PATCH] notmuch link

2011-10-06 Thread Tomi Ollila
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


tag sharing

2011-10-06 Thread David Bremner
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


tag sharing

2011-10-06 Thread Jesse Rosenthal
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

2011-10-06 Thread Jesse Rosenthal
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`


tag sharing

2011-10-06 Thread David Bremner
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

2011-10-06 Thread David Bremner
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


[PATCH 1/2] emacs: add notmuch-show-refresh-view function

2011-10-06 Thread Jameson Graef Rollins
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

2011-10-06 Thread David Bremner
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

2011-10-06 Thread David Bremner

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



tweaks for handling parts in reply

2011-10-06 Thread Jameson Graef Rollins
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

2011-10-06 Thread David Bremner
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

2011-10-06 Thread Jesse Rosenthal
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: [PATCH] lib: make find_message{,by_filename) report errors

2011-10-06 Thread Sebastian Spaeth

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


Re: [python] can't find shared lib

2011-10-06 Thread Sebastian Spaeth
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: tag sharing

2011-10-06 Thread David Bremner
On Wed, 08 Jun 2011 10:46:57 -0700, Jameson Graef Rollins 
jroll...@finestructure.net wrote:

 On Mon, 06 Jun 2011 13:20:00 -0400, Jesse Rosenthal jrosent...@jhu.edu 
 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: [PATCH 1/2] emacs: add notmuch-show-refresh-view function

2011-10-06 Thread David Bremner
On Sat, 28 May 2011 17:09:43 -0700, Jameson Graef Rollins 
jroll...@finestructure.net 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: [PATCH 1/2] emacs: add notmuch-show-refresh-view function

2011-10-06 Thread David Bremner
On Sat, 28 May 2011 17:09:43 -0700, Jameson Graef Rollins 
jroll...@finestructure.net 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: tag sharing

2011-10-06 Thread David Bremner
On Thu, 06 Oct 2011 09:21:48 -0400, Jesse Rosenthal jrosent...@jhu.edu 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: tag sharing

2011-10-06 Thread Jesse Rosenthal
On Thu, 06 Oct 2011 09:56:43 -0300, David Bremner da...@tethera.net 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:

TIMESTAMPMESSAGID TAG
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: [RFC/PATCH] notmuch link

2011-10-06 Thread Tomi Ollila
On Tue 04 Oct 2011 00:15, Ali Polatel pola...@gmail.com 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: tweaks for handling parts in reply

2011-10-06 Thread Jameson Graef Rollins
On Thu, 06 Oct 2011 10:29:52 -0300, David Bremner da...@tethera.net 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


Re: [PATCH 1/2] emacs: add notmuch-show-refresh-view function

2011-10-06 Thread Jameson Graef Rollins
On Thu, 06 Oct 2011 10:35:14 -0300, David Bremner da...@tethera.net 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


Re: tag sharing

2011-10-06 Thread Jesse Rosenthal
On Thu, 06 Oct 2011 11:18:51 -0300, David Bremner da...@tethera.net 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


Re: tag sharing

2011-10-06 Thread David Bremner
On Thu, 06 Oct 2011 15:49:10 -0400, Jesse Rosenthal jrosent...@jhu.edu 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

2011-10-06 Thread Jesse Rosenthal
On Thu, 06 Oct 2011 17:23:21 -0300, David Bremner da...@tethera.net 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

2011-10-06 Thread David Bremner
On Thu, 06 Oct 2011 16:40:00 -0400, Jesse Rosenthal jrosent...@jhu.edu wrote:
 On Thu, 06 Oct 2011 17:23:21 -0300, David Bremner da...@tethera.net 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


output file argument to notmuch dump.

2011-10-06 Thread David Bremner

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 search-term

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


Re: output file argument to notmuch dump.

2011-10-06 Thread Dmitry Kurochkin
On Thu, 06 Oct 2011 21:20:40 -0300, David Bremner brem...@unb.ca 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 search-term
 
 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


Re: output file argument to notmuch dump.

2011-10-06 Thread David Bremner
On Fri, 07 Oct 2011 04:37:56 +0400, Dmitry Kurochkin 
dmitry.kuroch...@gmail.com wrote:
 On Thu, 06 Oct 2011 21:20:40 -0300, David Bremner brem...@unb.ca 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


Re: output file argument to notmuch dump.

2011-10-06 Thread Jameson Graef Rollins
On Thu, 06 Oct 2011 21:20:40 -0300, David Bremner brem...@unb.ca 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