query on a subset of messages ?

[Sebastien Binet]

Sebastien Binet  writes:

> Austin Clements  writes:
>
>> Quoth Sebastien Binet on Jul 09 at 10:25 am:
>>> 
>>> hi there,
>>> 
>>> I was trying to reduce the I/O stress during my usual email
>>> fetching+tagging by writing a little program using the go bindings to
>>> notmuch.
>>> 
>>> ie:
>>> db, status := notmuch.OpenDatabase(db_path,
>>> notmuch.DATABASE_MODE_READ_WRITE)
>>> query := db.CreateQuery("(tag:new AND tag:inbox)")
>>> msgs := query.SearchMessages()
>>> for _,msg := range msgs {
>>>   tag_msg(msg, tagqueries)
>>> }
>>> 
>>> 
>>> where tagqueries is a subquery of the form:
>>> [
>>> {
>>> "Cmd": "+to-me",
>>> "Query": "(to:sebastien.binet at cern.ch and not tag:to-me)"
>>> },
>>> {
>>> "Cmd": "+sci-notmuch",
>>> "Query": "from:notmuch at notmuchmail.org or to:notmuch at 
>>> notmuchmail.org or subject:notmuch"
>>> }
>>> ]
>>> 
>>> 
>>> the idea being that I only need to crawl through the db only once and
>>> then iteratively apply tags on those messages (instead of repeatedly
>>> running "notmuch tag ..." for each and every of those many
>>> 'tag-queries')
>>> 
>>> I couldn't find any C-API to do such a thing using the notmuch library.
>>> did I overlook something ?
>>> 
>>> Is it something useful to add ?
>>> 
>>> -s
>>
>> Have you tried a more direct translation of the multiple notmuch tag
>> commands into Go, where you don't worry about subsetting the queries?
>> Unless you're tagging a huge number of messages, the cost of notmuch
>> tag is almost certainly the fsync that it does when it closes the
>> database (which every call to notmuch tag must do).  However, in Go,
>> you can keep the database open across all of the tagging operations
>> and then close and fsync it just once.
>
> nope, I haven't tried that, but will do.
>
>>
>> Note that there is an important optimization in notmuch tag that you
>> might have to replicate.  It manipulates the original query to exclude
>> messages that already have the desired tags, so that they get skipped
>> very efficiently at the earliest stage possible.
> I already have this in my original shell script.
> (wouldn't be too hard to automatically do, though.)

FYI, I've put this into a new notmuch-mtag go-based binary over here:
https://github.com/sbinet/notmuch/blob/dev/go-bindings/bindings/go/src/notmuch-mtag/main.go


-s
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: not available
URL: 
<http://notmuchmail.org/pipermail/notmuch/attachments/20120719/4a91371d/attachment-0001.pgp>

Re: query on a subset of messages ?

[Sebastien Binet]

Sebastien Binet bi...@cern.ch writes:

 Austin Clements amdra...@mit.edu writes:

 Quoth Sebastien Binet on Jul 09 at 10:25 am:
 
 hi there,
 
 I was trying to reduce the I/O stress during my usual email
 fetching+tagging by writing a little program using the go bindings to
 notmuch.
 
 ie:
 db, status := notmuch.OpenDatabase(db_path,
 notmuch.DATABASE_MODE_READ_WRITE)
 query := db.CreateQuery((tag:new AND tag:inbox))
 msgs := query.SearchMessages()
 for _,msg := range msgs {
   tag_msg(msg, tagqueries)
 }
 
 
 where tagqueries is a subquery of the form:
 [
 {
 Cmd: +to-me,
 Query: (to:sebastien.bi...@cern.ch and not tag:to-me)
 },
 {
 Cmd: +sci-notmuch,
 Query: from:notmuch@notmuchmail.org or 
 to:notmuch@notmuchmail.org or subject:notmuch
 }
 ]
 
 
 the idea being that I only need to crawl through the db only once and
 then iteratively apply tags on those messages (instead of repeatedly
 running notmuch tag ... for each and every of those many
 'tag-queries')
 
 I couldn't find any C-API to do such a thing using the notmuch library.
 did I overlook something ?
 
 Is it something useful to add ?
 
 -s

 Have you tried a more direct translation of the multiple notmuch tag
 commands into Go, where you don't worry about subsetting the queries?
 Unless you're tagging a huge number of messages, the cost of notmuch
 tag is almost certainly the fsync that it does when it closes the
 database (which every call to notmuch tag must do).  However, in Go,
 you can keep the database open across all of the tagging operations
 and then close and fsync it just once.

 nope, I haven't tried that, but will do.


 Note that there is an important optimization in notmuch tag that you
 might have to replicate.  It manipulates the original query to exclude
 messages that already have the desired tags, so that they get skipped
 very efficiently at the earliest stage possible.
 I already have this in my original shell script.
 (wouldn't be too hard to automatically do, though.)

FYI, I've put this into a new notmuch-mtag go-based binary over here:
https://github.com/sbinet/notmuch/blob/dev/go-bindings/bindings/go/src/notmuch-mtag/main.go


-s


pgplTbd26fv2U.pgp
Description: PGP signature
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch

[PATCH 1/7] go: Use iota in enum bindings

[Sebastien Binet]

Austin Clements  writes:

> Hah.  I guess nobody has tried to modify a notmuch database using the
> Go bindings.
>
> Could this instead assign the constants to
> C.NOTMUCH_DATABASE_MODE_READ_ONLY, etc, rather than duplicating their
> values?  It would be nice to do that for the Status values as well
> (which are correctly using iota, at least).

yep.
I have a few fixes like that in my repo:
https://github.com/sbinet/notmuch/commits/dev/go-bindings/bindings/go/src/notmuch

https://github.com/sbinet/notmuch/commit/38713de1b90a29b66b2a7f310065a3ffcf527d9b#L1L88

-s
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: not available
URL: 

Re: [PATCH 1/7] go: Use iota in enum bindings

[Sebastien Binet]

Austin Clements amdra...@mit.edu writes:

 Hah.  I guess nobody has tried to modify a notmuch database using the
 Go bindings.

 Could this instead assign the constants to
 C.NOTMUCH_DATABASE_MODE_READ_ONLY, etc, rather than duplicating their
 values?  It would be nice to do that for the Status values as well
 (which are correctly using iota, at least).

yep.
I have a few fixes like that in my repo:
https://github.com/sbinet/notmuch/commits/dev/go-bindings/bindings/go/src/notmuch

https://github.com/sbinet/notmuch/commit/38713de1b90a29b66b2a7f310065a3ffcf527d9b#L1L88

-s


pgpXK4y5mdBMb.pgp
Description: PGP signature
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch

post-new [was: Re: query on a subset of messages ?]

[Sebastien Binet]

Jani Nikula  writes:

> On Jul 9, 2012 8:12 PM, "Jameson Graef Rollins"  finestructure.net>
> wrote:
>>
>> On Mon, Jul 09 2012, Sebastien Binet  wrote:
>> > hum... is post-new supposed to be run even if there is no new message ?
>>
>> Hi, Sebastian.  Yes, I think it runs regardless if there are any new
>> messages or not.
>
> That's correct; only errors in notmuch new cause post-new hook to be
> skipped.

ok. I thought using the post-new hook would have saved some i/o
resources over my current setup:
 offlineimap.postsynchook = ~/emacs/notmuch-lib/notmuch-tag.sh

where notmuch-tag.sh is (in pseudo-code):
##
/usr/bin/notmuch new

for tag,query in tag-queries:
  tag_new $tag $query

##

is there any advantage of using post-new compared to this setup ?

-s
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: not available
URL: 
<http://notmuchmail.org/pipermail/notmuch/attachments/20120710/8e3e0334/attachment.pgp>

Re: post-new [was: Re: query on a subset of messages ?]

[Sebastien Binet]

Jani Nikula j...@nikula.org writes:

 On Jul 9, 2012 8:12 PM, Jameson Graef Rollins jroll...@finestructure.net
 wrote:

 On Mon, Jul 09 2012, Sebastien Binet bi...@cern.ch wrote:
  hum... is post-new supposed to be run even if there is no new message ?

 Hi, Sebastian.  Yes, I think it runs regardless if there are any new
 messages or not.

 That's correct; only errors in notmuch new cause post-new hook to be
 skipped.

ok. I thought using the post-new hook would have saved some i/o
resources over my current setup:
 offlineimap.postsynchook = ~/emacs/notmuch-lib/notmuch-tag.sh

where notmuch-tag.sh is (in pseudo-code):
##
/usr/bin/notmuch new

for tag,query in tag-queries:
  tag_new $tag $query

##

is there any advantage of using post-new compared to this setup ?

-s


pgpUHrMkBjuFt.pgp
Description: PGP signature
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch

query on a subset of messages ?

[Sebastien Binet]

Austin Clements  writes:

> Quoth Sebastien Binet on Jul 09 at 10:25 am:
>> 
>> hi there,
>> 
>> I was trying to reduce the I/O stress during my usual email
>> fetching+tagging by writing a little program using the go bindings to
>> notmuch.
>> 
>> ie:
>> db, status := notmuch.OpenDatabase(db_path,
>>  notmuch.DATABASE_MODE_READ_WRITE)
>> query := db.CreateQuery("(tag:new AND tag:inbox)")
>> msgs := query.SearchMessages()
>> for _,msg := range msgs {
>>   tag_msg(msg, tagqueries)
>> }
>> 
>> 
>> where tagqueries is a subquery of the form:
>> [
>> {
>> "Cmd": "+to-me",
>> "Query": "(to:sebastien.binet at cern.ch and not tag:to-me)"
>> },
>> {
>> "Cmd": "+sci-notmuch",
>> "Query": "from:notmuch at notmuchmail.org or to:notmuch at 
>> notmuchmail.org or subject:notmuch"
>> }
>> ]
>> 
>> 
>> the idea being that I only need to crawl through the db only once and
>> then iteratively apply tags on those messages (instead of repeatedly
>> running "notmuch tag ..." for each and every of those many
>> 'tag-queries')
>> 
>> I couldn't find any C-API to do such a thing using the notmuch library.
>> did I overlook something ?
>> 
>> Is it something useful to add ?
>> 
>> -s
>
> Have you tried a more direct translation of the multiple notmuch tag
> commands into Go, where you don't worry about subsetting the queries?
> Unless you're tagging a huge number of messages, the cost of notmuch
> tag is almost certainly the fsync that it does when it closes the
> database (which every call to notmuch tag must do).  However, in Go,
> you can keep the database open across all of the tagging operations
> and then close and fsync it just once.

nope, I haven't tried that, but will do.

>
> Note that there is an important optimization in notmuch tag that you
> might have to replicate.  It manipulates the original query to exclude
> messages that already have the desired tags, so that they get skipped
> very efficiently at the earliest stage possible.
I already have this in my original shell script.
(wouldn't be too hard to automatically do, though.)

-s
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: not available
URL: 
<http://notmuchmail.org/pipermail/notmuch/attachments/20120709/bfc4612a/attachment.pgp>

post-new [was: Re: query on a subset of messages ?]

[Sebastien Binet]

Sebastien Binet  writes:

> Jamie,
>
> Jameson Graef Rollins  writes:
>
>> On Mon, Jul 09 2012, Sebastien Binet  wrote:
>>> I was trying to reduce the I/O stress during my usual email
>>> fetching+tagging by writing a little program using the go bindings to
>>> notmuch.
>>>
>>> ie:
>>> db, status := notmuch.OpenDatabase(db_path,
>>> notmuch.DATABASE_MODE_READ_WRITE)
>>> query := db.CreateQuery("(tag:new AND tag:inbox)")
>>> msgs := query.SearchMessages()
>>> for _,msg := range msgs {
>>>   tag_msg(msg, tagqueries)
>>> }
>>>
>>>
>>> where tagqueries is a subquery of the form:
>>> [
>>> {
>>> "Cmd": "+to-me",
>>> "Query": "(to:sebastien.binet at cern.ch and not tag:to-me)"
>>> },
>>> {
>>> "Cmd": "+sci-notmuch",
>>> "Query": "from:notmuch at notmuchmail.org or to:notmuch at 
>>> notmuchmail.org or subject:notmuch"
>>> }
>>> ]
>>
>>
>> Hi, Sebastian.  It's really hard for me to believe that this is much
>> faster than simply making the two tagging calls in full:
>>
>> notmuch tag +to-me -- tag:new and tag:inbox and (to:sebastien.binet at 
>> cern.ch and not tag:to-me)
>> notmuch tag +sci-notmuch -- tag:new and tag:inbox and from:notmuch at 
>> notmuchmail.org or to:notmuch at notmuchmail.org or subject:notmuch"
>>
>> After the first call the cache will be fresh, so the overhead should be
>> minimal.  It looks to me you're looking in to this as a post-new hook.
>> I do pretty much the same thing, and with the above properly constructed
>> searches the tagging is super fast.
>
> well, of course I don't have just those two:
>
> $ grep -He "^tag_new " emacs/notmuch-lib/notmuch-tag.sh | wc -l
> 54
>
> also:
> $ du -hs mail-notmuch/.notmuch 
> 2.9G  mail-notmuch/.notmuch
>
> that said, most of the I/O wait seem to come from 'notmuch new' (after
> having dropped all fs caches.)
>
> ok, post-new hook it is then :)

hum... is post-new supposed to be run even if there is no new message ?

-s
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: not available
URL: 
<http://notmuchmail.org/pipermail/notmuch/attachments/20120709/32d8f4bc/attachment.pgp>

query on a subset of messages ?

[Sebastien Binet]

Jamie,

Jameson Graef Rollins  writes:

> On Mon, Jul 09 2012, Sebastien Binet  wrote:
>> I was trying to reduce the I/O stress during my usual email
>> fetching+tagging by writing a little program using the go bindings to
>> notmuch.
>>
>> ie:
>> db, status := notmuch.OpenDatabase(db_path,
>>  notmuch.DATABASE_MODE_READ_WRITE)
>> query := db.CreateQuery("(tag:new AND tag:inbox)")
>> msgs := query.SearchMessages()
>> for _,msg := range msgs {
>>   tag_msg(msg, tagqueries)
>> }
>>
>>
>> where tagqueries is a subquery of the form:
>> [
>> {
>> "Cmd": "+to-me",
>> "Query": "(to:sebastien.binet at cern.ch and not tag:to-me)"
>> },
>> {
>> "Cmd": "+sci-notmuch",
>> "Query": "from:notmuch at notmuchmail.org or to:notmuch at 
>> notmuchmail.org or subject:notmuch"
>> }
>> ]
>
>
> Hi, Sebastian.  It's really hard for me to believe that this is much
> faster than simply making the two tagging calls in full:
>
> notmuch tag +to-me -- tag:new and tag:inbox and (to:sebastien.binet at 
> cern.ch and not tag:to-me)
> notmuch tag +sci-notmuch -- tag:new and tag:inbox and from:notmuch at 
> notmuchmail.org or to:notmuch at notmuchmail.org or subject:notmuch"
>
> After the first call the cache will be fresh, so the overhead should be
> minimal.  It looks to me you're looking in to this as a post-new hook.
> I do pretty much the same thing, and with the above properly constructed
> searches the tagging is super fast.

well, of course I don't have just those two:

$ grep -He "^tag_new " emacs/notmuch-lib/notmuch-tag.sh | wc -l
54

also:
$ du -hs mail-notmuch/.notmuch 
2.9Gmail-notmuch/.notmuch

that said, most of the I/O wait seem to come from 'notmuch new' (after
having dropped all fs caches.)

ok, post-new hook it is then :)

(but there is probably something to do to speed-up a 'notmuch new' after
having dropped all fs caches... ?)

-s
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: not available
URL: 
<http://notmuchmail.org/pipermail/notmuch/attachments/20120709/f8f7106d/attachment.pgp>

query on a subset of messages ?

[Sebastien Binet]

hi there,

I was trying to reduce the I/O stress during my usual email
fetching+tagging by writing a little program using the go bindings to
notmuch.

ie:
db, status := notmuch.OpenDatabase(db_path,
notmuch.DATABASE_MODE_READ_WRITE)
query := db.CreateQuery("(tag:new AND tag:inbox)")
msgs := query.SearchMessages()
for _,msg := range msgs {
  tag_msg(msg, tagqueries)
}


where tagqueries is a subquery of the form:
[
{
"Cmd": "+to-me",
"Query": "(to:sebastien.binet at cern.ch and not tag:to-me)"
},
{
"Cmd": "+sci-notmuch",
"Query": "from:notmuch at notmuchmail.org or to:notmuch at 
notmuchmail.org or subject:notmuch"
}
]


the idea being that I only need to crawl through the db only once and
then iteratively apply tags on those messages (instead of repeatedly
running "notmuch tag ..." for each and every of those many
'tag-queries')

I couldn't find any C-API to do such a thing using the notmuch library.
did I overlook something ?

Is it something useful to add ?

-s
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: not available
URL: 

query on a subset of messages ?

[Sebastien Binet]

hi there,

I was trying to reduce the I/O stress during my usual email
fetching+tagging by writing a little program using the go bindings to
notmuch.

ie:
db, status := notmuch.OpenDatabase(db_path,
notmuch.DATABASE_MODE_READ_WRITE)
query := db.CreateQuery((tag:new AND tag:inbox))
msgs := query.SearchMessages()
for _,msg := range msgs {
  tag_msg(msg, tagqueries)
}


where tagqueries is a subquery of the form:
[
{
Cmd: +to-me,
Query: (to:sebastien.bi...@cern.ch and not tag:to-me)
},
{
Cmd: +sci-notmuch,
Query: from:notmuch@notmuchmail.org or to:notmuch@notmuchmail.org or 
subject:notmuch
}
]


the idea being that I only need to crawl through the db only once and
then iteratively apply tags on those messages (instead of repeatedly
running notmuch tag ... for each and every of those many
'tag-queries')

I couldn't find any C-API to do such a thing using the notmuch library.
did I overlook something ?

Is it something useful to add ?

-s


pgpHNeEYn2Kzh.pgp
Description: PGP signature
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch

Re: query on a subset of messages ?

[Sebastien Binet]

Jamie,

Jameson Graef Rollins jroll...@finestructure.net writes:

 On Mon, Jul 09 2012, Sebastien Binet bi...@cern.ch wrote:
 I was trying to reduce the I/O stress during my usual email
 fetching+tagging by writing a little program using the go bindings to
 notmuch.

 ie:
 db, status := notmuch.OpenDatabase(db_path,
  notmuch.DATABASE_MODE_READ_WRITE)
 query := db.CreateQuery((tag:new AND tag:inbox))
 msgs := query.SearchMessages()
 for _,msg := range msgs {
   tag_msg(msg, tagqueries)
 }


 where tagqueries is a subquery of the form:
 [
 {
 Cmd: +to-me,
 Query: (to:sebastien.bi...@cern.ch and not tag:to-me)
 },
 {
 Cmd: +sci-notmuch,
 Query: from:notmuch@notmuchmail.org or to:notmuch@notmuchmail.org 
 or subject:notmuch
 }
 ]


 Hi, Sebastian.  It's really hard for me to believe that this is much
 faster than simply making the two tagging calls in full:

 notmuch tag +to-me -- tag:new and tag:inbox and (to:sebastien.bi...@cern.ch 
 and not tag:to-me)
 notmuch tag +sci-notmuch -- tag:new and tag:inbox and 
 from:notmuch@notmuchmail.org or to:notmuch@notmuchmail.org or subject:notmuch

 After the first call the cache will be fresh, so the overhead should be
 minimal.  It looks to me you're looking in to this as a post-new hook.
 I do pretty much the same thing, and with the above properly constructed
 searches the tagging is super fast.

well, of course I don't have just those two:

$ grep -He ^tag_new  emacs/notmuch-lib/notmuch-tag.sh | wc -l
54

also:
$ du -hs mail-notmuch/.notmuch 
2.9Gmail-notmuch/.notmuch

that said, most of the I/O wait seem to come from 'notmuch new' (after
having dropped all fs caches.)

ok, post-new hook it is then :)

(but there is probably something to do to speed-up a 'notmuch new' after
having dropped all fs caches... ?)

-s


pgpicxOcCMNSN.pgp
Description: PGP signature
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch

post-new [was: Re: query on a subset of messages ?]

[Sebastien Binet]

Sebastien Binet bi...@cern.ch writes:

 Jamie,

 Jameson Graef Rollins jroll...@finestructure.net writes:

 On Mon, Jul 09 2012, Sebastien Binet bi...@cern.ch wrote:
 I was trying to reduce the I/O stress during my usual email
 fetching+tagging by writing a little program using the go bindings to
 notmuch.

 ie:
 db, status := notmuch.OpenDatabase(db_path,
 notmuch.DATABASE_MODE_READ_WRITE)
 query := db.CreateQuery((tag:new AND tag:inbox))
 msgs := query.SearchMessages()
 for _,msg := range msgs {
   tag_msg(msg, tagqueries)
 }


 where tagqueries is a subquery of the form:
 [
 {
 Cmd: +to-me,
 Query: (to:sebastien.bi...@cern.ch and not tag:to-me)
 },
 {
 Cmd: +sci-notmuch,
 Query: from:notmuch@notmuchmail.org or 
 to:notmuch@notmuchmail.org or subject:notmuch
 }
 ]


 Hi, Sebastian.  It's really hard for me to believe that this is much
 faster than simply making the two tagging calls in full:

 notmuch tag +to-me -- tag:new and tag:inbox and (to:sebastien.bi...@cern.ch 
 and not tag:to-me)
 notmuch tag +sci-notmuch -- tag:new and tag:inbox and 
 from:notmuch@notmuchmail.org or to:notmuch@notmuchmail.org or 
 subject:notmuch

 After the first call the cache will be fresh, so the overhead should be
 minimal.  It looks to me you're looking in to this as a post-new hook.
 I do pretty much the same thing, and with the above properly constructed
 searches the tagging is super fast.

 well, of course I don't have just those two:

 $ grep -He ^tag_new  emacs/notmuch-lib/notmuch-tag.sh | wc -l
 54

 also:
 $ du -hs mail-notmuch/.notmuch 
 2.9G  mail-notmuch/.notmuch

 that said, most of the I/O wait seem to come from 'notmuch new' (after
 having dropped all fs caches.)

 ok, post-new hook it is then :)

hum... is post-new supposed to be run even if there is no new message ?

-s


pgpii7diIsl6t.pgp
Description: PGP signature
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch

Re: query on a subset of messages ?

[Sebastien Binet]

Austin Clements amdra...@mit.edu writes:

 Quoth Sebastien Binet on Jul 09 at 10:25 am:
 
 hi there,
 
 I was trying to reduce the I/O stress during my usual email
 fetching+tagging by writing a little program using the go bindings to
 notmuch.
 
 ie:
 db, status := notmuch.OpenDatabase(db_path,
  notmuch.DATABASE_MODE_READ_WRITE)
 query := db.CreateQuery((tag:new AND tag:inbox))
 msgs := query.SearchMessages()
 for _,msg := range msgs {
   tag_msg(msg, tagqueries)
 }
 
 
 where tagqueries is a subquery of the form:
 [
 {
 Cmd: +to-me,
 Query: (to:sebastien.bi...@cern.ch and not tag:to-me)
 },
 {
 Cmd: +sci-notmuch,
 Query: from:notmuch@notmuchmail.org or to:notmuch@notmuchmail.org 
 or subject:notmuch
 }
 ]
 
 
 the idea being that I only need to crawl through the db only once and
 then iteratively apply tags on those messages (instead of repeatedly
 running notmuch tag ... for each and every of those many
 'tag-queries')
 
 I couldn't find any C-API to do such a thing using the notmuch library.
 did I overlook something ?
 
 Is it something useful to add ?
 
 -s

 Have you tried a more direct translation of the multiple notmuch tag
 commands into Go, where you don't worry about subsetting the queries?
 Unless you're tagging a huge number of messages, the cost of notmuch
 tag is almost certainly the fsync that it does when it closes the
 database (which every call to notmuch tag must do).  However, in Go,
 you can keep the database open across all of the tagging operations
 and then close and fsync it just once.

nope, I haven't tried that, but will do.


 Note that there is an important optimization in notmuch tag that you
 might have to replicate.  It manipulates the original query to exclude
 messages that already have the desired tags, so that they get skipped
 very efficiently at the earliest stage possible.
I already have this in my original shell script.
(wouldn't be too hard to automatically do, though.)

-s


pgpLiejugYF8M.pgp
Description: PGP signature
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch

Re: [PATCH] go: Update to the current notmuch_database_find_message API

[Sebastien Binet]

Justus,

Justus Winter 4win...@informatik.uni-hamburg.de writes:

 Quoting David Bremner (2012-04-30 13:53:47)
 Austin Clements amdra...@mit.edu writes:
 
  The signature of notmuch_database_find_message was changed in 02a30767
  to report errors and the Go bindings were never updated.  This brings
  the Go bindings in sync with that change and at least makes them
  compile with Go r60.3, the last release before Go 1.
 
 I don't have any easy way to test this, since the current versions in 
 Debian are all based on Go 1.  On the other hand I guess it doesn't make
 things worse.  Anybody have any objections to this patch?

 lgtm.

 In the long run we have to decide what to do about these bindings. Seb
 (or anyone else) are you interested in porting them to Go 1 and
 maintaining them?  Otherwise it may be time to deprecate them.

 I care enough for the go environment to keep the go bindings
 working. I've updated the bindings, the build infrastructure and the
 notmuch-addrlookup utility to go 1. I'll send a patch series as a
 followup that is meant to be applied upon Austins patch.

 The last patch in the series is a cleanup of the source code done with
 the gofmt utility. Go is somewhat strict in its coding conventions,
 but there is a utility that magically formats code. This makes the go
 code in the wild remarkably consistent. We should stick to the
 conventions too, hence this patch even if it breaks git blame
 somewhat.

 I haven't tested the bindings in depth, but the notmuch-addrlookup
 utility seems to be working fine.

kudos for picking this up.
I must say I don't use these go bindings in anger anymore: this was
mainly a test project for go.
(I am still a happy go user as well as a notmuch one, though, but I
prefer bbdb to notmuch-addrlookup)

-s



pgpe4HPMM3DQJ.pgp
Description: PGP signature
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch

bug in emacs-ui ?

[Sebastien Binet]

Dmitry,

On Wed, 29 Jun 2011 05:53:37 +0400, Dmitry Kurochkin  wrote:
> On Tue, 28 Jun 2011 21:38:17 +0400, Dmitry Kurochkin  gmail.com> wrote:
> > Hi Jani.
> > 
> > On Tue, 28 Jun 2011 10:35:48 + (UTC), Jani Nikula  
> > wrote:
> > > Carl Worth  writes:
> > > 
> > > > 
> > > > On Wed, 22 Jun 2011 08:50:23 +0200, Sebastien Binet
> > > >  wrote:
> > > > > On Tue, 21 Jun 2011 15:09:20 -0700, Carl Worth  wrote:
> > > > > > Perhaps this is an emacs bug?
> > > > > could be, but,
> > > > > 
> > > > > > I'm using Debian's emacs 23.3.1 and have not encountered the problem
> > > > > > described.
> > > > > I don't see anything related to 'point', 'point-invisible-p' nor
> > > 'forward-char' in there:
> > > > > http://patch-tracker.debian.org/package/emacs23/23.3+1-1
> > > > 
> > > > Perhaps I was confused. I thought 23.3.1 was a distinct upstream release
> > > > From 23.3, but maybe not, (emacs version numbers use 1-based indexing
> > > > perhaps?).
> > > > 
> > > > > anyways... for the moment I'll just live with it...
> > > > 
> > > > Sorry about that.
> > > > 
> > > > > except if somebody has some insights on how to "catch" the 'End of
> > > > > buffer' error and add some more protective programming around the
> > > > > 'scroll-up' function ?
> > > > 
> > > > My emacs lisp skills are primarily restricted to actual
> > > > experimentation. So if I can replicate the bug, I might be able to find
> > > > a fix. I'm not very good at doing theoretical fixes with emacs lisp
> > > > code.
> > > 
> > > I bisected the problem to commit 95ef8da29439f2e79115c36ab4d2a80aef1a1462 
> > > ("Fix
> > > hiding a message while some citations are shown in notmuch-show view").
> > > Reverting that fixes the problem for me. (If you don't want to resolve
> > > conflicts, also revert 432e091924c1d1d8950a44ca78bc5b9c5ade47e4 first.) I 
> > > don't
> > > have the time just now to try to figure out the problem in that, but 
> > > perhaps
> > > this will help others go forward.
> > > 
> > 
> > Thanks for tracking this.  I will look into it.
> > 
> 
> I have posted a patch to fix this bug [1].

thanks a lot for figuring this one out.
I'll give it a try!

-s

-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: not available
URL: 
<http://notmuchmail.org/pipermail/notmuch/attachments/20110629/6c21858b/attachment.pgp>

bug in emacs-ui ?

[Sebastien Binet]

hi,

On Mon, 20 Jun 2011 22:41:18 -0700, Jameson Graef Rollins  wrote:
Non-text part: multipart/signed
> On Tue, 21 Jun 2011 02:01:17 +0200, Sebastien Binet  
> wrote:
> > and I checked there were no lingering .el files...
> > 
> > so...
> >  any way to tell which notmuch-emacs-ui I am actually using ? (I am a newbie
> > when comes to hacking lisp)
> 
> Hey, Sebastien.  You can determine the loaded version of a library from
> within emacs with the follow command:
> 
> M-x locate-library notmuch
> 
> It's also good to know how many notmuch instances are installed on your
> system.  For instance, I have a system-wide installation, a "personal"
> installation, the build currently in the source tree, etc.  Depending on
> the options I supply to emacs at startup, I could run a variety of
> versions.

so, it seems the problem comes from:

(defun notmuch-show-advance-and-archive ()
  "Advance through thread and archive."
  (interactive)
  (let ((end-of-this-message (notmuch-show-message-bottom)))
(cond
 ;; Ideally we would test `end-of-this-message' against the result
 ;; of `window-end', but that doesn't account for the fact that
 ;; the end of the message might be hidden, so we have to actually
 ;; go to the end, walk back over invisible text and then see if
 ;; point is visible.
 ((save-excursion
(message "pt00: %s" (point))
(goto-char (- end-of-this-message 1))
(message "pt01: %s" (point))
(notmuch-show-move-past-invisible-backward)
(message "msg-end: %s" end-of-this-message)
(message "pt11: %s" (point))
;;(goto-char (- (point) 400))
(message "pt12: %s" (point))
(> (point) (window-end)))
  (message "point: %s" (point))
  (message "window-end: %s" (window-end))
  ;; The bottom of this message is not visible - scroll.
  (scroll-up nil))
 ((not (= end-of-this-message (point-max)))
  ;; This is not the last message - move to the next visible one.
  (notmuch-show-next-open-message))

where I've added some good ol' print "foo" debugging.

using the message from the openmpi mailing list I sent earlier and
pressing tab, I get in the *Messages* buffer:

For information about GNU Emacs and the GNU system, type C-h C-a.
pt00: 1
pt01: 1392
msg-end: #
pt11: 1392
pt12: 1392
point: 1
window-end: 1113
notmuch-show-advance-and-archive: End of buffer 

   
ie: it would seem the notmuch-show-move-past-invisible-backward does
*not* move the point up to just before the hidden signature (and does
not move it at all.)

if I uncomment the goto-char to -400 line, everything's fine. (400 is
roughly the length of the hidden signature)

well, this is just an educated guess from an emacs-lisp programmer
complete newbie.

fyi: I am using emacs-23.3
no patch were applied on top of the vanilla sources:
http://projects.archlinux.org/svntogit/packages.git/tree/emacs/repos/extra-x86_64/PKGBUILD

-s
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: not available
URL: 
<http://notmuchmail.org/pipermail/notmuch/attachments/20110621/e5903cf2/attachment.pgp>

bug in emacs-ui ?

[Sebastien Binet]

On Mon, 20 Jun 2011 22:41:18 -0700, Jameson Graef Rollins  wrote:
Non-text part: multipart/signed
> On Tue, 21 Jun 2011 02:01:17 +0200, Sebastien Binet  
> wrote:
> > and I checked there were no lingering .el files...
> > 
> > so...
> >  any way to tell which notmuch-emacs-ui I am actually using ? (I am a newbie
> > when comes to hacking lisp)
> 
> Hey, Sebastien.  You can determine the loaded version of a library from
> within emacs with the follow command:
> 
> M-x locate-library notmuch
which points to the system-wide one.

> 
> It's also good to know how many notmuch instances are installed on your
> system.  For instance, I have a system-wide installation, a "personal"
> installation, the build currently in the source tree, etc.  Depending on
> the options I supply to emacs at startup, I could run a variety of
> versions.
being root and having this great ArchLinux package manager system at my
finger tips, I only have one installation of notmuch :)

playing a bit more, I cloned your 0.6 branch, cloned the official one,
slammed the 0.6/emacs directory on top of the official one, built the
official one, installed it and everything worked.

I am trying to see which changeset is the source of my problem...

-s
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: not available
URL: 
<http://notmuchmail.org/pipermail/notmuch/attachments/20110621/481666a3/attachment.pgp>

bug in emacs-ui ?

[Sebastien Binet]

hi,

On Mon, Jun 20, 2011 at 9:53 PM, Jameson Graef Rollins <
jrollins at finestructure.net> wrote:

> On Mon, 20 Jun 2011 18:43:01 +0200, Sebastien Binet 
> wrote:
> > > You didn't try forwarding the email to the list ;)
> > ah! that easy, heh ?
> >
> Attachment:
> 1300323326_0.6276.farnsworth,U=250482,FMD5=af1cd994dfcb9286c394d142687ff5a0:2,S
> (application/octet-stream)
>
> Hi, Sebastien.  I don't seem to have any problems viewing this message
> with notmuch emacs.  Is it possible that the notmuch emacs code you're
> running is out-of-sync with your notmuch binary?  I think that's a
> common source of problems like this.  Make sure that you're pointed to
> the version of the notmuch emacs libraries that corresponds to your
> notmuch binary, and that you've restarted your emacs session.  Hopefully
> that will fix things.
>

no joy:
$ `which notmuch` --version
notmuch 0.5-238-gc39b492

$ pacman -Ql notmuch-git
notmuch-git /etc/
notmuch-git /etc/bash_completion.d/
notmuch-git /etc/bash_completion.d/notmuch
notmuch-git /usr/
notmuch-git /usr/bin/
notmuch-git /usr/bin/notmuch
notmuch-git /usr/include/
notmuch-git /usr/include/notmuch.h
notmuch-git /usr/lib/
notmuch-git /usr/lib/libnotmuch.so
notmuch-git /usr/lib/libnotmuch.so.1
notmuch-git /usr/lib/libnotmuch.so.1.3.0
notmuch-git /usr/lib/python2.7/
 [other python files elided]
notmuch-git /usr/share/
notmuch-git /usr/share/emacs/
notmuch-git /usr/share/emacs/site-lisp/
notmuch-git /usr/share/emacs/site-lisp/coolj.el
notmuch-git /usr/share/emacs/site-lisp/coolj.elc
notmuch-git /usr/share/emacs/site-lisp/notmuch-address.el
notmuch-git /usr/share/emacs/site-lisp/notmuch-address.elc
notmuch-git /usr/share/emacs/site-lisp/notmuch-crypto.el
notmuch-git /usr/share/emacs/site-lisp/notmuch-crypto.elc
notmuch-git /usr/share/emacs/site-lisp/notmuch-hello.el
notmuch-git /usr/share/emacs/site-lisp/notmuch-hello.elc
notmuch-git /usr/share/emacs/site-lisp/notmuch-lib.el
notmuch-git /usr/share/emacs/site-lisp/notmuch-lib.elc
notmuch-git /usr/share/emacs/site-lisp/notmuch-logo.png
notmuch-git /usr/share/emacs/site-lisp/notmuch-maildir-fcc.el
notmuch-git /usr/share/emacs/site-lisp/notmuch-maildir-fcc.elc
notmuch-git /usr/share/emacs/site-lisp/notmuch-message.el
notmuch-git /usr/share/emacs/site-lisp/notmuch-message.elc
notmuch-git /usr/share/emacs/site-lisp/notmuch-mua.el
notmuch-git /usr/share/emacs/site-lisp/notmuch-mua.elc
notmuch-git /usr/share/emacs/site-lisp/notmuch-query.el
notmuch-git /usr/share/emacs/site-lisp/notmuch-query.elc
notmuch-git /usr/share/emacs/site-lisp/notmuch-show.el
notmuch-git /usr/share/emacs/site-lisp/notmuch-show.elc
notmuch-git /usr/share/emacs/site-lisp/notmuch-wash.el
notmuch-git /usr/share/emacs/site-lisp/notmuch-wash.elc
notmuch-git /usr/share/emacs/site-lisp/notmuch.el
notmuch-git /usr/share/emacs/site-lisp/notmuch.elc
notmuch-git /usr/share/man/
notmuch-git /usr/share/man/man1/
notmuch-git /usr/share/man/man1/notmuch.1.gz
notmuch-git /usr/share/vim/
notmuch-git /usr/share/vim/vimfiles/
notmuch-git /usr/share/vim/vimfiles/plugin/
notmuch-git /usr/share/vim/vimfiles/plugin/notmuch.vim
notmuch-git /usr/share/vim/vimfiles/syntax/
notmuch-git /usr/share/vim/vimfiles/syntax/notmuch-compose.vim
notmuch-git /usr/share/vim/vimfiles/syntax/notmuch-folders.vim
notmuch-git /usr/share/vim/vimfiles/syntax/notmuch-git-diff.vim
notmuch-git /usr/share/vim/vimfiles/syntax/notmuch-search.vim
notmuch-git /usr/share/vim/vimfiles/syntax/notmuch-show.vim
notmuch-git /usr/share/zsh/
notmuch-git /usr/share/zsh/functions/
notmuch-git /usr/share/zsh/functions/Completion/
notmuch-git /usr/share/zsh/functions/Completion/Unix/
notmuch-git /usr/share/zsh/functions/Completion/Unix/_notmuch

and I checked there were no lingering .el files...

so...
 any way to tell which notmuch-emacs-ui I am actually using ? (I am a newbie
when comes to hacking lisp)

-s
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://notmuchmail.org/pipermail/notmuch/attachments/20110621/21078348/attachment.html>

Re: bug in emacs-ui ?

[Sebastien Binet]

On Mon, 20 Jun 2011 22:41:18 -0700, Jameson Graef Rollins 
jroll...@finestructure.net wrote:
Non-text part: multipart/signed
 On Tue, 21 Jun 2011 02:01:17 +0200, Sebastien Binet seb.bi...@gmail.com 
 wrote:
  and I checked there were no lingering .el files...
  
  so...
   any way to tell which notmuch-emacs-ui I am actually using ? (I am a newbie
  when comes to hacking lisp)
 
 Hey, Sebastien.  You can determine the loaded version of a library from
 within emacs with the follow command:
 
 M-x locate-library notmuch
which points to the system-wide one.

 
 It's also good to know how many notmuch instances are installed on your
 system.  For instance, I have a system-wide installation, a personal
 installation, the build currently in the source tree, etc.  Depending on
 the options I supply to emacs at startup, I could run a variety of
 versions.
being root and having this great ArchLinux package manager system at my
finger tips, I only have one installation of notmuch :)

playing a bit more, I cloned your 0.6 branch, cloned the official one,
slammed the 0.6/emacs directory on top of the official one, built the
official one, installed it and everything worked.

I am trying to see which changeset is the source of my problem...

-s


pgpR8lM2HBb7H.pgp
Description: PGP signature
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch

Re: bug in emacs-ui ?

[Sebastien Binet]

hi,

On Mon, 20 Jun 2011 22:41:18 -0700, Jameson Graef Rollins 
jroll...@finestructure.net wrote:
Non-text part: multipart/signed
 On Tue, 21 Jun 2011 02:01:17 +0200, Sebastien Binet seb.bi...@gmail.com 
 wrote:
  and I checked there were no lingering .el files...
  
  so...
   any way to tell which notmuch-emacs-ui I am actually using ? (I am a newbie
  when comes to hacking lisp)
 
 Hey, Sebastien.  You can determine the loaded version of a library from
 within emacs with the follow command:
 
 M-x locate-library notmuch
 
 It's also good to know how many notmuch instances are installed on your
 system.  For instance, I have a system-wide installation, a personal
 installation, the build currently in the source tree, etc.  Depending on
 the options I supply to emacs at startup, I could run a variety of
 versions.

so, it seems the problem comes from:

(defun notmuch-show-advance-and-archive ()
  Advance through thread and archive.
  (interactive)
  (let ((end-of-this-message (notmuch-show-message-bottom)))
(cond
 ;; Ideally we would test `end-of-this-message' against the result
 ;; of `window-end', but that doesn't account for the fact that
 ;; the end of the message might be hidden, so we have to actually
 ;; go to the end, walk back over invisible text and then see if
 ;; point is visible.
 ((save-excursion
(message pt00: %s (point))
(goto-char (- end-of-this-message 1))
(message pt01: %s (point))
(notmuch-show-move-past-invisible-backward)
(message msg-end: %s end-of-this-message)
(message pt11: %s (point))
;;(goto-char (- (point) 400))
(message pt12: %s (point))
( (point) (window-end)))
  (message point: %s (point))
  (message window-end: %s (window-end))
  ;; The bottom of this message is not visible - scroll.
  (scroll-up nil))
 ((not (= end-of-this-message (point-max)))
  ;; This is not the last message - move to the next visible one.
  (notmuch-show-next-open-message))

where I've added some good ol' print foo debugging.

using the message from the openmpi mailing list I sent earlier and
pressing tab, I get in the *Messages* buffer:

For information about GNU Emacs and the GNU system, type C-h C-a.
pt00: 1
pt01: 1392
msg-end: #marker at 1393 in *[Open MPI Announce] Open MPI...
pt11: 1392
pt12: 1392
point: 1
window-end: 1113
notmuch-show-advance-and-archive: End of buffer 

   
ie: it would seem the notmuch-show-move-past-invisible-backward does
*not* move the point up to just before the hidden signature (and does
not move it at all.)

if I uncomment the goto-char to -400 line, everything's fine. (400 is
roughly the length of the hidden signature)

well, this is just an educated guess from an emacs-lisp programmer
complete newbie.

fyi: I am using emacs-23.3
no patch were applied on top of the vanilla sources:
http://projects.archlinux.org/svntogit/packages.git/tree/emacs/repos/extra-x86_64/PKGBUILD

-s


pgpeDHGJJ6NVX.pgp
Description: PGP signature
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch

bug in emacs-ui ?

[Sebastien Binet]

On Mon, 20 Jun 2011 11:18:11 -0700, Jameson Graef Rollins  wrote:
Non-text part: multipart/signed
> On Mon, 20 Jun 2011 18:43:01 +0200, Sebastien Binet  
> wrote:
> > > You didn't try forwarding the email to the list ;)
> > ah! that easy, heh ?
> >
> > Attachment: 
> > 1300323326_0.6276.farnsworth,U=250482,FMD5=af1cd994dfcb9286c394d142687ff5a0:2,S
> >  (application/octet-stream)
> 
> Are you sure this is the right message?  This message doesn't include
> any signature section that looks like the one that you posted before.
> The one you posted in your previous message was:
> 
> ___
> Message sent via/by LCG Savannah
> http://savannah.cern.ch/
> 
> This one is:
> 
> ___
> announce mailing list
> announce at open-mpi.org
> http://www.open-mpi.org/mailman/listinfo.cgi/announce

it is indeed another message but one which presents the same problem
(the other one was from a semi-private mailing list...)

> 
> Also (unrelated) I notice that the above attached message is not
> content-type "message/rfc822".  Specifying the right content type helps 
> receivers handle the messages a little better.
duly noted.

-s
-- 
#
# Dr. Sebastien Binet
# Laboratoire de l'Accelerateur Lineaire
# Universite Paris-Sud XI
# Batiment 200
# 91898 Orsay
#
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: not available
URL: 
<http://notmuchmail.org/pipermail/notmuch/attachments/20110620/fb2bc4e1/attachment.pgp>

bug in emacs-ui ?

[Sebastien Binet]

On Mon, 20 Jun 2011 09:17:32 -0700, Jameson Graef Rollins  wrote:
Non-text part: multipart/signed
> On Mon, 20 Jun 2011 17:52:03 +0200, Sebastien Binet  
> wrote:
> > it is only when the signature is lumped like below, that I get the error:
> >   [ 4-line signature. Click/Enter to show. ]
> > 
> > also, it's only happening to the last message of a thread.
> 
> Ah, ok.  Have you tried looking at the raw message?  Are there any
> strange characters or content after the signatures?
nope.
at least none that I can see.

> 
> > > If you feel comfortable doing so, it might help to forward the suspect
> > > message to the list.
> > 
> > I tried all the above, to no avail (ie: nothing on stderr.)
> 
> You didn't try forwarding the email to the list ;)
ah! that easy, heh ?

-- next part --
A non-text attachment was scrubbed...
Name: 
1300323326_0.6276.farnsworth,U=250482,FMD5=af1cd994dfcb9286c394d142687ff5a0:2,S
Type: application/octet-stream
Size: 5943 bytes
Desc: not available
URL: 
<http://notmuchmail.org/pipermail/notmuch/attachments/20110620/c7b11f13/attachment-0002.obj>
-- next part --

here is also the json dump of that message:
-- next part --
A non-text attachment was scrubbed...
Name: tmp.openmpi.message.json
Type: application/octet-stream
Size: 1680 bytes
Desc: not available
URL: 
<http://notmuchmail.org/pipermail/notmuch/attachments/20110620/c7b11f13/attachment-0003.obj>
-- next part --

hth,
-s
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: not available
URL: 
<http://notmuchmail.org/pipermail/notmuch/attachments/20110620/c7b11f13/attachment-0001.pgp>

bug in emacs-ui ?

[Sebastien Binet]

Jamie,

On Mon, 20 Jun 2011 08:16:00 -0700, Jameson Graef Rollins  wrote:
Non-text part: multipart/signed
> On Mon, 20 Jun 2011 09:15:06 +0200, Sebastien Binet  
> wrote:
> > recently, using the head of notmuch-git:
> > 
> >  git://notmuchmail.org/git/notmuch
> > 
> > when a mail ends with an url and is recognized as a signature:
> ...
> > I can't hit [space] to go to the next thread and I get the following
> > error:
> >  End of buffer
> 
> Hey, Sebastien.  I'm guessing that it is probably the *next* message in
> the thread that is the problem, not the end of the one that you're
> seeing.
I (naively) don't think so:
I don't get the error (which looks like that in the *Messages* buffer:
notmuch-show-advance-and-archive: End of buffer
)
if I unravel the signature:
  [ 4-line signature. Click/Enter to hide. ]
  ___
  Message sent via/by LCG Savannah
  http://savannah.cern.ch/

=> all is fine.

it is only when the signature is lumped like below, that I get the error:
  [ 4-line signature. Click/Enter to show. ]

also, it's only happening to the last message of a thread.

>  If you can determine the message id's of this message and the
> next one in the thread it will probably help with debugging.
> 
> If you haven't yet, it usually helps in debugging to view the messages
> in the terminal?  You can copy the thread-id into the clipboard by
> hitting "c i" when the cursor is over this thread in the notmuch search
> buffer, and then you can view the thread on the command line with:
> 
>   notmuch show thread:
> 
> It might be hard to see if there are any problems in the output, but you
> can at least see gmime is throwing an error by redirecting stdout to
> /dev/null:
> 
>   notmuch show thread: >/dev/null
> 
> You can try determining the message-ids with something like:
> 
>   notmuch show thread: | grep id
> 
> You can then view the raw messages with:
> 
>   notmuch show --format=raw id:
> 
> If you feel comfortable doing so, it might help to forward the suspect
> message to the list.

I tried all the above, to no avail (ie: nothing on stderr.)

> 
> > this does not show up when using the 'release-candidate/0.6' branch of:
> >  git://finestructure.net/notmuch
> 
> The release-candidate/0.6 is a bit out-of-date at the moment, as most of
> it's features have been incorporate into notmuch/master, and I doubt
> that the ones that haven't would be related to the issue you're
> seeing.

hum... I could try to bisect (but I've never done that before!)

-s
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: not available
URL: 
<http://notmuchmail.org/pipermail/notmuch/attachments/20110620/e775388c/attachment.pgp>

bug in emacs-ui ?

[Sebastien Binet]

hi there,

recently, using the head of notmuch-git:

 git://notmuchmail.org/git/notmuch

when a mail ends with an url and is recognized as a signature:

  
==

  This item URL is:


  [ 4-line signature. Click/Enter to hide. ]
  ___
  Message sent via/by LCG Savannah
  http://savannah.cern.ch/

I can't hit [space] to go to the next thread and I get the following
error:
 End of buffer

this does not show up when using the 'release-candidate/0.6' branch of:
 git://finestructure.net/notmuch

-s
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: not available
URL: 

bug in emacs-ui ?

[Sebastien Binet]

hi there,

recently, using the head of notmuch-git:

 git://notmuchmail.org/git/notmuch

when a mail ends with an url and is recognized as a signature:

  
==

  This item URL is:
http://savannah.cern.ch/bugs/?83337

  [ 4-line signature. Click/Enter to hide. ]
  ___
  Message sent via/by LCG Savannah
  http://savannah.cern.ch/

I can't hit [space] to go to the next thread and I get the following
error:
 End of buffer

this does not show up when using the 'release-candidate/0.6' branch of:
 git://finestructure.net/notmuch

-s


pgpyHLAUOL8pq.pgp
Description: PGP signature
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch

Re: bug in emacs-ui ?

[Sebastien Binet]

On Mon, 20 Jun 2011 11:18:11 -0700, Jameson Graef Rollins 
jroll...@finestructure.net wrote:
Non-text part: multipart/signed
 On Mon, 20 Jun 2011 18:43:01 +0200, Sebastien Binet seb.bi...@gmail.com 
 wrote:
   You didn't try forwarding the email to the list ;)
  ah! that easy, heh ?
 
  Attachment: 
  1300323326_0.6276.farnsworth,U=250482,FMD5=af1cd994dfcb9286c394d142687ff5a0:2,S
   (application/octet-stream)
 
 Are you sure this is the right message?  This message doesn't include
 any signature section that looks like the one that you posted before.
 The one you posted in your previous message was:
 
 ___
 Message sent via/by LCG Savannah
 http://savannah.cern.ch/
 
 This one is:
 
 ___
 announce mailing list
 annou...@open-mpi.org
 http://www.open-mpi.org/mailman/listinfo.cgi/announce

it is indeed another message but one which presents the same problem
(the other one was from a semi-private mailing list...)

 
 Also (unrelated) I notice that the above attached message is not
 content-type message/rfc822.  Specifying the right content type helps 
 receivers handle the messages a little better.
duly noted.

-s
-- 
#
# Dr. Sebastien Binet
# Laboratoire de l'Accelerateur Lineaire
# Universite Paris-Sud XI
# Batiment 200
# 91898 Orsay
#


pgpGH0OoyYZ7I.pgp
Description: PGP signature
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch

Re: bug in emacs-ui ?

[Sebastien Binet]

hi,

On Mon, Jun 20, 2011 at 9:53 PM, Jameson Graef Rollins 
jroll...@finestructure.net wrote:

 On Mon, 20 Jun 2011 18:43:01 +0200, Sebastien Binet seb.bi...@gmail.com
 wrote:
   You didn't try forwarding the email to the list ;)
  ah! that easy, heh ?
 
 Attachment:
 1300323326_0.6276.farnsworth,U=250482,FMD5=af1cd994dfcb9286c394d142687ff5a0:2,S
 (application/octet-stream)

 Hi, Sebastien.  I don't seem to have any problems viewing this message
 with notmuch emacs.  Is it possible that the notmuch emacs code you're
 running is out-of-sync with your notmuch binary?  I think that's a
 common source of problems like this.  Make sure that you're pointed to
 the version of the notmuch emacs libraries that corresponds to your
 notmuch binary, and that you've restarted your emacs session.  Hopefully
 that will fix things.


no joy:
$ `which notmuch` --version
notmuch 0.5-238-gc39b492

$ pacman -Ql notmuch-git
notmuch-git /etc/
notmuch-git /etc/bash_completion.d/
notmuch-git /etc/bash_completion.d/notmuch
notmuch-git /usr/
notmuch-git /usr/bin/
notmuch-git /usr/bin/notmuch
notmuch-git /usr/include/
notmuch-git /usr/include/notmuch.h
notmuch-git /usr/lib/
notmuch-git /usr/lib/libnotmuch.so
notmuch-git /usr/lib/libnotmuch.so.1
notmuch-git /usr/lib/libnotmuch.so.1.3.0
notmuch-git /usr/lib/python2.7/
 [other python files elided]
notmuch-git /usr/share/
notmuch-git /usr/share/emacs/
notmuch-git /usr/share/emacs/site-lisp/
notmuch-git /usr/share/emacs/site-lisp/coolj.el
notmuch-git /usr/share/emacs/site-lisp/coolj.elc
notmuch-git /usr/share/emacs/site-lisp/notmuch-address.el
notmuch-git /usr/share/emacs/site-lisp/notmuch-address.elc
notmuch-git /usr/share/emacs/site-lisp/notmuch-crypto.el
notmuch-git /usr/share/emacs/site-lisp/notmuch-crypto.elc
notmuch-git /usr/share/emacs/site-lisp/notmuch-hello.el
notmuch-git /usr/share/emacs/site-lisp/notmuch-hello.elc
notmuch-git /usr/share/emacs/site-lisp/notmuch-lib.el
notmuch-git /usr/share/emacs/site-lisp/notmuch-lib.elc
notmuch-git /usr/share/emacs/site-lisp/notmuch-logo.png
notmuch-git /usr/share/emacs/site-lisp/notmuch-maildir-fcc.el
notmuch-git /usr/share/emacs/site-lisp/notmuch-maildir-fcc.elc
notmuch-git /usr/share/emacs/site-lisp/notmuch-message.el
notmuch-git /usr/share/emacs/site-lisp/notmuch-message.elc
notmuch-git /usr/share/emacs/site-lisp/notmuch-mua.el
notmuch-git /usr/share/emacs/site-lisp/notmuch-mua.elc
notmuch-git /usr/share/emacs/site-lisp/notmuch-query.el
notmuch-git /usr/share/emacs/site-lisp/notmuch-query.elc
notmuch-git /usr/share/emacs/site-lisp/notmuch-show.el
notmuch-git /usr/share/emacs/site-lisp/notmuch-show.elc
notmuch-git /usr/share/emacs/site-lisp/notmuch-wash.el
notmuch-git /usr/share/emacs/site-lisp/notmuch-wash.elc
notmuch-git /usr/share/emacs/site-lisp/notmuch.el
notmuch-git /usr/share/emacs/site-lisp/notmuch.elc
notmuch-git /usr/share/man/
notmuch-git /usr/share/man/man1/
notmuch-git /usr/share/man/man1/notmuch.1.gz
notmuch-git /usr/share/vim/
notmuch-git /usr/share/vim/vimfiles/
notmuch-git /usr/share/vim/vimfiles/plugin/
notmuch-git /usr/share/vim/vimfiles/plugin/notmuch.vim
notmuch-git /usr/share/vim/vimfiles/syntax/
notmuch-git /usr/share/vim/vimfiles/syntax/notmuch-compose.vim
notmuch-git /usr/share/vim/vimfiles/syntax/notmuch-folders.vim
notmuch-git /usr/share/vim/vimfiles/syntax/notmuch-git-diff.vim
notmuch-git /usr/share/vim/vimfiles/syntax/notmuch-search.vim
notmuch-git /usr/share/vim/vimfiles/syntax/notmuch-show.vim
notmuch-git /usr/share/zsh/
notmuch-git /usr/share/zsh/functions/
notmuch-git /usr/share/zsh/functions/Completion/
notmuch-git /usr/share/zsh/functions/Completion/Unix/
notmuch-git /usr/share/zsh/functions/Completion/Unix/_notmuch

and I checked there were no lingering .el files...

so...
 any way to tell which notmuch-emacs-ui I am actually using ? (I am a newbie
when comes to hacking lisp)

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

address completion when composing

[Sebastien Binet]

On Wed, 11 May 2011 14:18:01 +0200, Florian Friesdorf  
wrote:
> 
> According to the docs [1], there are two programs that can be used with
> notmuch-address.el: notmuch-addresses (python) and addrlookup
> (vala/c).

for completeness...
there is also notmuch-addrlookup in go:
http://git.notmuchmail.org/git/notmuch/tree/HEAD:/bindings/go/cmds

(which is broken with the latest go release r57.1 because one of the 3rd
party package (to parse config files) is broken...)

> 
> Further it is possible to import all addresses into bbdb [2], supposedly
> faster than notmuch-address.el.
> 
> Is it also faster than notmuch-address.el + addrlookup? 
presumably: crawling thru the db is I/O bound...

> What about shipping some / all of these with notmuch? It feels that
> newbies would benefit from this inclusion and more extensive
> documentation about what to do to get address completion.
> 
> Probably it would be sane to decide either for notmuch-addresses or
> addrlookup, as they seem to do the same.
> 
> In addition the import script for bbdb could be nice.
+1

-s
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: not available
URL: 

ordering threads by the latest message in a thread ?

[Sebastien Binet]

On Wed, 9 Feb 2011 13:36:17 -0500, Jesse Rosenthal  
wrote:
> 
> On Wed, 09 Feb 2011 13:22:26 -0500, Daniel Kahn Gillmor  fifthhorseman.net> wrote:
> > 
> > Jameson, are you saying that "Search Oldest First" not only inverts the
> > order of the threads, but also changes the a date a given thread is
> > associated with?  
> 
> The procedure is to match threads by either the oldest matching message
> (in oldest first) or newest matching message (in newest first). So
> matching newest first will make the thread with new messages go to the
> top. But in oldest first -- which is what I imagine Sebastian was
> looking at in the inbox -- the thread with an older inbox message will
> appear further up.
> 
> So if Sebastian's message is tagged "inbox" this thread will appear,
> under oldest-first, when he sent it; if it's not but Jamie's is, then it
> will appear under Jamie's. But it'll appear under mine regardless in
> newest first. I don't believe emacs has anything to do with it -- it's
> how the nm binary orders threads as output to "search."

aha!
I knew about the 'o' toggle that one could play with to display the
threads, but I didn't notice this also modified how their ordering
worked out: 
 I naively thought it was just a matter of reverting the list.

so, say I have the following messages and threads:
 id_0 1/3 [important meeting] - (received Monday)
 id_1 2/3  [important meeting] - (received Tuesday)
 id_2 1/1 [pick groceries] - (received Wednesday)
 id_3 3/3   [important meeting] - (received Thursday)
 id_4 1/1 [another title] - (received Friday morning)

if I have 'Search Oldest first' "on", I'd get the following
 id_0 [and id_1 and id_3 folded in]
 id_2 
 id_4

and if it is "off":
 id_4
 id_0 [and id_1 and id_3 folded in]
 id_2

but what I'd like to have is instead:
 id_2
 id_0 [and id_1 and id_3 folded in]
 id_4

id_0 and friends come after id_2 because id_3 is more recent than id_2
but older than id_4

so: oldest first but only the latest of the messages of a thread to be
considered for the thread-to-thread ordering.

I prefer to process my emails like a stack growing from top to bottom ;)

-s
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: not available
URL: 

ordering threads by the latest message in a thread ?

[Sebastien Binet]

hi there,

right now, it seems like the messages are displayed and ordered in my
inbox according to the date of the *first* message in a thread.

that doesn't sound right to me as one can easily miss new replies to
that thread (at least I did.)

is there a way to modify this in the notmuch emacs interface so that
threads are ordered according to the *latest* message in a thread
instead ?
(I am not fluent in lisp -- even if I am regularly trying to work on
that specific issue -- so I might have missed an obvious way to perform
such a thing.)

-- 
@+
-s
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: not available
URL: 

ordering threads by the latest message in a thread ?

[Sebastien Binet]

hi there,

right now, it seems like the messages are displayed and ordered in my
inbox according to the date of the *first* message in a thread.

that doesn't sound right to me as one can easily miss new replies to
that thread (at least I did.)

is there a way to modify this in the notmuch emacs interface so that
threads are ordered according to the *latest* message in a thread
instead ?
(I am not fluent in lisp -- even if I am regularly trying to work on
that specific issue -- so I might have missed an obvious way to perform
such a thing.)

-- 
@+
-s


pgpJbaRfII32Q.pgp
Description: PGP signature
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch

Re: ordering threads by the latest message in a thread ?

[Sebastien Binet]

On Wed, 9 Feb 2011 13:36:17 -0500, Jesse Rosenthal jrosent...@jhu.edu wrote:
 
 On Wed, 09 Feb 2011 13:22:26 -0500, Daniel Kahn Gillmor 
 d...@fifthhorseman.net wrote:
  
  Jameson, are you saying that Search Oldest First not only inverts the
  order of the threads, but also changes the a date a given thread is
  associated with?  
 
 The procedure is to match threads by either the oldest matching message
 (in oldest first) or newest matching message (in newest first). So
 matching newest first will make the thread with new messages go to the
 top. But in oldest first -- which is what I imagine Sebastian was
 looking at in the inbox -- the thread with an older inbox message will
 appear further up.
 
 So if Sebastian's message is tagged inbox this thread will appear,
 under oldest-first, when he sent it; if it's not but Jamie's is, then it
 will appear under Jamie's. But it'll appear under mine regardless in
 newest first. I don't believe emacs has anything to do with it -- it's
 how the nm binary orders threads as output to search.

aha!
I knew about the 'o' toggle that one could play with to display the
threads, but I didn't notice this also modified how their ordering
worked out: 
 I naively thought it was just a matter of reverting the list.

so, say I have the following messages and threads:
 id_0 1/3 [important meeting] - (received Monday)
 id_1 2/3  [important meeting] - (received Tuesday)
 id_2 1/1 [pick groceries] - (received Wednesday)
 id_3 3/3   [important meeting] - (received Thursday)
 id_4 1/1 [another title] - (received Friday morning)

if I have 'Search Oldest first' on, I'd get the following
 id_0 [and id_1 and id_3 folded in]
 id_2 
 id_4

and if it is off:
 id_4
 id_0 [and id_1 and id_3 folded in]
 id_2

but what I'd like to have is instead:
 id_2
 id_0 [and id_1 and id_3 folded in]
 id_4

id_0 and friends come after id_2 because id_3 is more recent than id_2
but older than id_4

so: oldest first but only the latest of the messages of a thread to be
considered for the thread-to-thread ordering.

I prefer to process my emails like a stack growing from top to bottom ;)

-s


pgpfwSXtAcTaE.pgp
Description: PGP signature
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch

[ann] (incomplete) go bindings to libnotmuch

[Sebastien Binet]

On Thu, 11 Nov 2010 16:50:06 -0800, Carl Worth  wrote:
> On Wed, 10 Nov 2010 18:37:00 +0100, Sebastien Binet  wrote:
> 
> > mainly to familiarize myself with the go language, I wrapped the
> > libnotmuch library and reaped off Sebastian's vala-addressbooklookup
> > program into a go version.
> > 
> > the buggy and incomplete code is there:
> >  http://bitbucket.org/binet/go-notmuch/src
> 
> Cool stuff.
> 
> Having wrappers and code for a library I'm familiar with like this would
> make it much easier for me to sit down and take a good look at go.
> 
> Would be you be interested in maintaining these within the bindings/
> directory of the main notmuch repository? Let me know.
sure, no problem.

cheers,
sebastien.

Re: [ann] (incomplete) go bindings to libnotmuch

[Sebastien Binet]

On Thu, 11 Nov 2010 16:50:06 -0800, Carl Worth cwo...@cworth.org wrote:
 On Wed, 10 Nov 2010 18:37:00 +0100, Sebastien Binet bi...@cern.ch wrote:
 
  mainly to familiarize myself with the go language, I wrapped the
  libnotmuch library and reaped off Sebastian's vala-addressbooklookup
  program into a go version.
  
  the buggy and incomplete code is there:
   http://bitbucket.org/binet/go-notmuch/src
 
 Cool stuff.
 
 Having wrappers and code for a library I'm familiar with like this would
 make it much easier for me to sit down and take a good look at go.
 
 Would be you be interested in maintaining these within the bindings/
 directory of the main notmuch repository? Let me know.
sure, no problem.

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

[ann] (incomplete) go bindings to libnotmuch

[Sebastien Binet]

hi there,

mainly to familiarize myself with the go language, I wrapped the
libnotmuch library and reaped off Sebastian's vala-addressbooklookup
program into a go version.

the buggy and incomplete code is there:
 http://bitbucket.org/binet/go-notmuch/src

cheers,
sebastien.

[ann] (incomplete) go bindings to libnotmuch

[Sebastien Binet]

hi there,

mainly to familiarize myself with the go language, I wrapped the
libnotmuch library and reaped off Sebastian's vala-addressbooklookup
program into a go version.

the buggy and incomplete code is there:
 http://bitbucket.org/binet/go-notmuch/src

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