[PATCH] potential fix for nmbug merge problems

2014-09-23 Thread David Bremner
---
 scripts/nmbug | 5 -
 1 file changed, 4 insertions(+), 1 deletion(-)

This seems to fix the problems with merges failing on dirty indexes.
I didn't have time to trace through all of the ramifications, but it
seems to me by doing a merge with the default index, we are getting
some kind of random state (or maybe the state of the last merge).

I'll have to road test this a bit more to be sure it's a fix, but maybe you can 
think about whether it's the righ thing (TM) to do in any case.

diff --git a/scripts/nmbug b/scripts/nmbug
index 77bec64..47e4ee8 100755
--- a/scripts/nmbug
+++ b/scripts/nmbug
@@ -457,10 +457,13 @@ def merge(reference='@{upstream}'):
 The default reference is '@{upstream}'.
 """
 _insist_committed()
+path = _os.path.join(NMBGIT, 'nmbug.index')
+
 with _tempfile.TemporaryDirectory(prefix='nmbug-merge.') as workdir:
 _git(
 args=['merge', reference],
-additional_env={'GIT_WORK_TREE': workdir},
+additional_env={'GIT_WORK_TREE': workdir,
+'GIT_INDEX_FILE': path},
 wait=True)
 checkout()

-- 
2.1.0



[PATCH 03/11] emacs: Fix coding system in `notmuch-show-view-raw-message'

2014-09-23 Thread David Bremner
Austin Clements  writes:

> This fixes the known-broken test of viewing 8bit messages added by the
> previous commit.

I pushed the first 3 patches in the series.

d


[PATCH] python: Add binding for notmuch_query_add_tag_exclude

2014-09-23 Thread David Bremner
Thibaut Horel  writes:

> Implemented as the method `exclude_tag` of the class `Query`. This
> method takes one argument, a string containing the name of the tag to
> exclude

pushed, thanks

d


[PATCH] python: Add binding for notmuch_query_add_tag_exclude

2014-09-23 Thread Justus Winter
Quoting David Bremner (2014-09-20 07:15:02)
> Thibaut Horel  writes:
> 
> > Implemented as the method `exclude_tag` of the class `Query`. This method 
> > takes
> > one argument, a string containing the name of the tag to exclude
> 
> This tag looks pretty trivial.  I'll merge it unless I hear some
> objections over the weekend.

It looks fine indeed, thanks to the both of you.  The only tricky
thing I remember is the py2/py3 string/unicode thing, for which I seem
to have created the _str function, so it should be fine indeed.

Justus


[PATCH] Add configurable changed tag to messages that have been changed on disk

2014-09-23 Thread Gaute Hope
22. sep. 2014 17:40 skrev "Austin Clements" 
f?lgende:
>
> On Mon, 22 Sep 2014, Gaute Hope  wrote:
> > Excerpts from Gaute Hope's message of August 6, 2014 10:29:
> >> Austin Clements  wrote on Fri, 01 Aug 2014 14:55:05
-0400:
> >>> I have a prototype implementation of message modification times on my
> >>> lastmod-v1 branch at
> >>>
> >>>   https://github.com/aclements/notmuch/tree/lastmod-v1
> >>>
> >>> It builds on my database features series that's currently awaiting
> >>> review [1].
> >>>
> >>> The series uses a monotonic revision number, rather than wall-clock
> >>> time, for reasons related to Xapian's concurrent control and detailed
> >>> in the main commit's commit message.  The implementation isn't quite
> >>> useful from the CLI yet because I haven't added any way to query the
> >>> database's current revision number.  (I'm still thinking about how I
> >>> want to do this, since search/show don't have a good way to deliver
> >>> "additional" information right now.  I might just add the last
> >>> modification for each individual message/max of all messages in a
> >>> thread, similar to what Thomas Jost's patch did long ago.)
> >>>
> >>> [1] id:1406859003-11561-1-git-send-email-amdragon at mit.edu
> >
> >> this should allow me to do what I wish to accomplish. The message
> >> deletion is still a problem though, I can see two options at the
moment:
> >
> > Hi list,
> >
> > While exploring the possibility of syncing maildir/X-keywords with tags
> > I had some thoughts about lastmod and message modification:
> >
> > As briefly discussed on #notmuch, I noticed that it seems that 'notmuch
> > new' does not detect that a message source has been changed, unless the
> > file is also re-named.
> >
> > This means that for instance if the X-Keywords fields have been updated
> > in a message (from GMail with offlineimap, synclabels = yes) the lastmod
> > field will remain unchanged, and a source modification will be
> > undetectable to a client program using this value.
> >
> > Would it not make sense that if a message has a more recent mtime than
> > at index time it is re-indexed?
>
> This has the potential to make notmuch new substantially more expensive.
> Currently, if there are no changes, it only has to stat each directory
> in your maildir (in fact, some restructuring of new would let us
> eliminate almost all database access during a no-op notmuch new as
> well).  Checking for changes to individual messages would require
> stat'ing every single message file as well as accessing the database to
> check the paths and mtimes of every message, increasing the number of
> stat calls and disk accesses by several orders of magnitude.
>
> It may be that this is fast enough that it's okay, but it would be good
> to gather some evidence first.  That includes hot and cold caches, and
> maildir over NFS.
>
> With respect to X-Keywords specifically, note that it's a fairly basic
> design decision that notmuch never modifies message files.  This gives
> us strong robustness guarantees we would be loathe to part with.
>
> It has puzzled me ever since offlineimap added X-Keywords why they
> didn't just translate these keywords into folders and create hard links
> of message files.  Anything could interact smoothly with that.

The information follows the message file. But, yeah, working directly on
the message source is hairy. Anyway, email is as mess in general anyway. I
consider it user-input.

>
> > Also, for the lastmod branch I would wish for a notmuch_message_touch()
> > method where the lastmod time is updated to the last. As well as a
> > notmuch_database_reindex_message () - possibly defined/documented
> > behaviour for notmuch_database_add_message () when the filename is
> > already added (in which case I would expect notmuch to re-index the
> > message).
>
> What's the use case for these?

If you make a change to the message source and want it to be reindexed.
Say, edited a draft or changed a header field. I am not asking that notmuch
modifies the message source.

For _touch, if without making an actual change to the message you wish to
indicate that it has been updated or synced at the current time. For
instance after an reindex that did not make any actual change. Perhaps not
strictly necessary.

Cheers, Gaute
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://notmuchmail.org/pipermail/notmuch/attachments/20140923/54ff8117/attachment.html>


Do path: searches handle spaces correctly?

2014-09-23 Thread David Bremner
Keith Amidon  writes:

>
> What do you think about adding a section to the notmuch-search-terms web
> page that talks in more detail about the quoting interactions?  If there
> were on obvious section about this in the man page it might have helped
> me find the issue myself.  If this seems like a good idea I'll take a
> crack at it later this week when I get time to research the Xapian
> quoting in a bit more detail.

Yes, it makes sense to add such a section.

d


Re: Do path: searches handle spaces correctly?

2014-09-23 Thread David Bremner
Keith Amidon cama...@picnicpark.org writes:


 What do you think about adding a section to the notmuch-search-terms web
 page that talks in more detail about the quoting interactions?  If there
 were on obvious section about this in the man page it might have helped
 me find the issue myself.  If this seems like a good idea I'll take a
 crack at it later this week when I get time to research the Xapian
 quoting in a bit more detail.

Yes, it makes sense to add such a section.

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


Re: [PATCH] Add configurable changed tag to messages that have been changed on disk

2014-09-23 Thread Gaute Hope
22. sep. 2014 17:40 skrev Austin Clements acleme...@csail.mit.edu
følgende:

 On Mon, 22 Sep 2014, Gaute Hope e...@gaute.vetsj.com wrote:
  Excerpts from Gaute Hope's message of August 6, 2014 10:29:
  Austin Clements amdra...@mit.edu wrote on Fri, 01 Aug 2014 14:55:05
-0400:
  I have a prototype implementation of message modification times on my
  lastmod-v1 branch at
 
https://github.com/aclements/notmuch/tree/lastmod-v1
 
  It builds on my database features series that's currently awaiting
  review [1].
 
  The series uses a monotonic revision number, rather than wall-clock
  time, for reasons related to Xapian's concurrent control and detailed
  in the main commit's commit message.  The implementation isn't quite
  useful from the CLI yet because I haven't added any way to query the
  database's current revision number.  (I'm still thinking about how I
  want to do this, since search/show don't have a good way to deliver
  additional information right now.  I might just add the last
  modification for each individual message/max of all messages in a
  thread, similar to what Thomas Jost's patch did long ago.)
 
  [1] id:1406859003-11561-1-git-send-email-amdra...@mit.edu
 
  this should allow me to do what I wish to accomplish. The message
  deletion is still a problem though, I can see two options at the
moment:
 
  Hi list,
 
  While exploring the possibility of syncing maildir/X-keywords with tags
  I had some thoughts about lastmod and message modification:
 
  As briefly discussed on #notmuch, I noticed that it seems that 'notmuch
  new' does not detect that a message source has been changed, unless the
  file is also re-named.
 
  This means that for instance if the X-Keywords fields have been updated
  in a message (from GMail with offlineimap, synclabels = yes) the lastmod
  field will remain unchanged, and a source modification will be
  undetectable to a client program using this value.
 
  Would it not make sense that if a message has a more recent mtime than
  at index time it is re-indexed?

 This has the potential to make notmuch new substantially more expensive.
 Currently, if there are no changes, it only has to stat each directory
 in your maildir (in fact, some restructuring of new would let us
 eliminate almost all database access during a no-op notmuch new as
 well).  Checking for changes to individual messages would require
 stat'ing every single message file as well as accessing the database to
 check the paths and mtimes of every message, increasing the number of
 stat calls and disk accesses by several orders of magnitude.

 It may be that this is fast enough that it's okay, but it would be good
 to gather some evidence first.  That includes hot and cold caches, and
 maildir over NFS.

 With respect to X-Keywords specifically, note that it's a fairly basic
 design decision that notmuch never modifies message files.  This gives
 us strong robustness guarantees we would be loathe to part with.

 It has puzzled me ever since offlineimap added X-Keywords why they
 didn't just translate these keywords into folders and create hard links
 of message files.  Anything could interact smoothly with that.

The information follows the message file. But, yeah, working directly on
the message source is hairy. Anyway, email is as mess in general anyway. I
consider it user-input.


  Also, for the lastmod branch I would wish for a notmuch_message_touch()
  method where the lastmod time is updated to the last. As well as a
  notmuch_database_reindex_message () - possibly defined/documented
  behaviour for notmuch_database_add_message () when the filename is
  already added (in which case I would expect notmuch to re-index the
  message).

 What's the use case for these?

If you make a change to the message source and want it to be reindexed.
Say, edited a draft or changed a header field. I am not asking that notmuch
modifies the message source.

For _touch, if without making an actual change to the message you wish to
indicate that it has been updated or synced at the current time. For
instance after an reindex that did not make any actual change. Perhaps not
strictly necessary.

Cheers, Gaute
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch


Re: [PATCH 03/11] emacs: Fix coding system in `notmuch-show-view-raw-message'

2014-09-23 Thread David Bremner
Austin Clements amdra...@mit.edu writes:

 This fixes the known-broken test of viewing 8bit messages added by the
 previous commit.

I pushed the first 3 patches in the series.

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


[PATCH] potential fix for nmbug merge problems

2014-09-23 Thread David Bremner
---
 scripts/nmbug | 5 -
 1 file changed, 4 insertions(+), 1 deletion(-)

This seems to fix the problems with merges failing on dirty indexes.
I didn't have time to trace through all of the ramifications, but it
seems to me by doing a merge with the default index, we are getting
some kind of random state (or maybe the state of the last merge).

I'll have to road test this a bit more to be sure it's a fix, but maybe you can 
think about whether it's the righ thing (TM) to do in any case.

diff --git a/scripts/nmbug b/scripts/nmbug
index 77bec64..47e4ee8 100755
--- a/scripts/nmbug
+++ b/scripts/nmbug
@@ -457,10 +457,13 @@ def merge(reference='@{upstream}'):
 The default reference is '@{upstream}'.
 
 _insist_committed()
+path = _os.path.join(NMBGIT, 'nmbug.index')
+
 with _tempfile.TemporaryDirectory(prefix='nmbug-merge.') as workdir:
 _git(
 args=['merge', reference],
-additional_env={'GIT_WORK_TREE': workdir},
+additional_env={'GIT_WORK_TREE': workdir,
+'GIT_INDEX_FILE': path},
 wait=True)
 checkout()
 
-- 
2.1.0

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