[PATCH] python/thread: always return a string in get_subject/authors

2011-05-09 Thread Anton Khirnov
Now None is returned when those don't exist, which is inconvenient to
deal with.
---
 bindings/python/notmuch/thread.py |6 --
 1 files changed, 4 insertions(+), 2 deletions(-)

diff --git a/bindings/python/notmuch/thread.py 
b/bindings/python/notmuch/thread.py
index eebd6cb..cf26957 100644
--- a/bindings/python/notmuch/thread.py
+++ b/bindings/python/notmuch/thread.py
@@ -281,7 +281,8 @@ class Thread(object):
 
 if self._thread is None:
 raise NotmuchError(STATUS.NOT_INITIALIZED)
-return Thread._get_authors(self._thread)
+ret = Thread._get_authors(self._thread)
+return ret if ret else ''
 
 def get_subject(self):
 Returns the Subject of 'thread'
@@ -291,7 +292,8 @@ class Thread(object):
 
 if self._thread is None:
 raise NotmuchError(STATUS.NOT_INITIALIZED)
-return Thread._get_subject(self._thread)
+ret = Thread._get_subject(self._thread)
+return ret if ret else ''
 
 def get_newest_date(self):
 Returns time_t of the newest message date
-- 
1.7.4.4

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


[PATCH] Use message-field-value instead of message-fetch-field in FCC header setup.

2011-05-09 Thread Dmitry Kurochkin
For message-fetch-field the buffer is expected to be narrowed to
just the header of the message.  That is not the case when
notmuch-fcc-header-setup is run, hence a wrong header value may be
returned.  E.g. when forwarding an
email, (message-fetch-field From) returns the From header value
of the forwarded email.

Message-field-value is the same as message-fetch-field, only
narrows the buffer to the headers first.
---

The patch is for the release-candidate/0.6 branch.  It is an amended
version of a patch I sent a while ago
id:1278000507-22290-4-git-send-email-dmitry.kuroch...@gmail.com.

Regards,
  Dmitry


 emacs/notmuch-maildir-fcc.el |6 +++---
 1 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/emacs/notmuch-maildir-fcc.el b/emacs/notmuch-maildir-fcc.el
index 3f1c124..aede753 100644
--- a/emacs/notmuch-maildir-fcc.el
+++ b/emacs/notmuch-maildir-fcc.el
@@ -80,7 +80,7 @@ will NOT be removed or replaced.
   (let ((subdir
 (cond
  ((or (not notmuch-fcc-dirs)
-  (message-fetch-field Fcc))
+  (message-field-value Fcc))
   ;; Nothing set or an existing header.
   nil)
 
@@ -93,7 +93,7 @@ will NOT be removed or replaced.
   (error Invalid `notmuch-fcc-dirs' setting (old style)))
 
  ((listp notmuch-fcc-dirs)
-  (let* ((from (message-fetch-field From))
+  (let* ((from (message-field-value From))
  (match
   (catch 'first-match
 (dolist (re-folder notmuch-fcc-dirs)
@@ -118,7 +118,7 @@ will NOT be removed or replaced.
  (concat (notmuch-database-path) / subdir)
   
   ;; finally test if fcc points to a valid maildir
-  (let ((fcc-header (message-fetch-field Fcc)))
+  (let ((fcc-header (message-field-value Fcc)))
(unless (notmuch-maildir-fcc-dir-is-maildir-p fcc-header)
  (cond ((not (file-writable-p fcc-header))
 (error (format No permission to create %s, which does not 
exist
-- 
1.7.5.1

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


Re: [PATCH] python/thread: always return a string in get_subject/authors

2011-05-09 Thread Austin Clements
Your commit message is inconsistent with your change; is your intent to
return None or the empty string?  Also, could you modify your commit message
to say what those are?
On May 9, 2011 3:06 AM, Anton Khirnov an...@khirnov.net wrote:
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch


Re: [PATCH] python/thread: always return a string in get_subject/authors

2011-05-09 Thread David Bremner
On Mon,  9 May 2011 09:06:34 +0200, Anton Khirnov an...@khirnov.net wrote:
 Now None is returned when those don't exist, which is inconvenient to
 deal with.

I'm not using the python bindings, but from a philosophical point of
view, this change makes me a bit uncomfortable since it apparently
merges two cases together, and makes an error (no Subject)
indistinguishable from an odd situation (Subject of empty string).
Or am I missing something here?

All the best,

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


Re: [PATCH] lib/message-file: plug three memleaks.

2011-05-09 Thread Austin Clements
Cool.  This looks like a pretty nasty leak and I'm pretty sure your
patch is correct (though it took me a while to convince myself!).

My one nit is code style.  There should be a space between the
function name and the paren.  (Oddly, the is_received handling that
you changed is the only place in notmuch where I've seen this style
violated; but there's no sense in spreading this inconsistency.)

On Mon, May 9, 2011 at 2:46 AM, Anton Khirnov an...@khirnov.net wrote:
 On Fri, 15 Apr 2011 16:43:58 +0200, Anton Khirnov an...@khirnov.net wrote:
 ---
  lib/message-file.c |    5 +
  1 files changed, 5 insertions(+), 0 deletions(-)

 diff --git a/lib/message-file.c b/lib/message-file.c
 index 7722832..b7b3286 100644
 --- a/lib/message-file.c
 +++ b/lib/message-file.c
 @@ -341,12 +341,17 @@ notmuch_message_file_get_header 
 (notmuch_message_file_t *message,
               strncpy(combined_header,header_sofar,hdrsofar);
               *(combined_header+hdrsofar) = ' ';
               strncpy(combined_header+hdrsofar+1,decoded_value,newhdr+1);
 +             free(decoded_value);
               g_hash_table_insert (message-headers, header, 
 combined_header);
           }
       } else {
           if (header_sofar == NULL) {
               /* Only insert if we don't have a value for this header, yet. 
 */
               g_hash_table_insert (message-headers, header, decoded_value);
 +         } else {
 +             free(header);
 +             free(decoded_value);
 +             decoded_value = header_sofar;
           }
       }
       /* if we found a match we can bail - unless of course we are
 --
 1.7.4.1

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

 ping

 --
 Anton Khirnov
 ___
 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: [PATCH] python/thread: always return a string in get_subject/authors

2011-05-09 Thread servilio
On 9 May 2011 08:20, David Bremner da...@tethera.net wrote:
 On Mon,  9 May 2011 09:06:34 +0200, Anton Khirnov an...@khirnov.net wrote:
 Now None is returned when those don't exist, which is inconvenient to
 deal with.

 I'm not using the python bindings, but from a philosophical point of
 view, this change makes me a bit uncomfortable since it apparently
 merges two cases together, and makes an error (no Subject)
 indistinguishable from an odd situation (Subject of empty string).
 Or am I missing something here?

I see the the same issue.

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


Re: release-candidate/0.6

2011-05-09 Thread micah anderson
On Fri, 06 May 2011 12:46:34 -0700, Jameson Graef Rollins 
jroll...@finestructure.net wrote:

 I might try to add a couple of more things before declaring the
 candidate release-ready, but this is more-or-less it.  Please start
 using this branch in production as much as possible, so that we can
 build up a chorus of support for pushing this release out.  Once you
 have build, tested, and started using the branch, please reply to this
 email thread to express your support for it's release.

I've been using this branch now for a couple of days and its solid,
thanks for pulling this together Mr. Rollins.

 The release-candidate/0.6 branch also includes debian package updates,
 so you should be able to easily build debian packages from the branch:
 
 git buildpackage -uc -us --git-ignore-branch

I used this mechanism to build a package and install it, it worked
well. I also ran lintian on it just to see if there were any issues, but
you get an A+.

micah


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


Re: [PATCH] python/thread: always return a string in get_subject/authors

2011-05-09 Thread Anton Khirnov
On Mon, 09 May 2011 09:20:41 -0300, David Bremner da...@tethera.net wrote:
 On Mon,  9 May 2011 09:06:34 +0200, Anton Khirnov an...@khirnov.net wrote:
  Now None is returned when those don't exist, which is inconvenient to
  deal with.
 
 I'm not using the python bindings, but from a philosophical point of
 view, this change makes me a bit uncomfortable since it apparently
 merges two cases together, and makes an error (no Subject)
 indistinguishable from an odd situation (Subject of empty string).
 Or am I missing something here?

The question is whether this is really a problem.

For a single message, it might make sense to distinguish between 'no
header' and 'empty header'.

But those aren't message headers, those are thread properties. And I'd
argue that a thread always has authors and a subject (possibly empty).

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


[PATCH] lib/message-file: plug three memleaks.

2011-05-09 Thread Anton Khirnov
---
 lib/message-file.c |5 +
 1 files changed, 5 insertions(+), 0 deletions(-)

diff --git a/lib/message-file.c b/lib/message-file.c
index 7722832..99505c1 100644
--- a/lib/message-file.c
+++ b/lib/message-file.c
@@ -341,12 +341,17 @@ notmuch_message_file_get_header (notmuch_message_file_t 
*message,
strncpy(combined_header,header_sofar,hdrsofar);
*(combined_header+hdrsofar) = ' ';
strncpy(combined_header+hdrsofar+1,decoded_value,newhdr+1);
+   free (decoded_value);
g_hash_table_insert (message-headers, header, combined_header);
}
} else {
if (header_sofar == NULL) {
/* Only insert if we don't have a value for this header, yet. */
g_hash_table_insert (message-headers, header, decoded_value);
+   } else {
+   free (header);
+   free (decoded_value);
+   decoded_value = header_sofar;
}
}
/* if we found a match we can bail - unless of course we are
-- 
1.7.5.1

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


Re: [PATCH] python/thread: always return a string in get_subject/authors

2011-05-09 Thread Jesse Rosenthal
On Mon, 09 May 2011 17:13:10 +0200, Anton Khirnov an...@khirnov.net wrote:
 But those aren't message headers, those are thread properties. And I'd
 argue that a thread always has authors and a subject (possibly empty).

The RFC says yes on the author, no on the subject. The only things
guaranteed are From: and originating timestamp. So I'm not sure why
subject should be guaranteed a string result and not, say, Cc. 

My sense is that Python users are prety good with testing against None,
especially since (not ) == (not []) == (not None) == True. This change
seems like it would end up producing more inconsistencies with the way
you deal with headers, by producing special cases.

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


Re: [PATCH] python/thread: always return a string in get_subject/authors

2011-05-09 Thread Jesse Rosenthal

On Mon, 09 May 2011 11:23:16 -0400, Jesse Rosenthal jrosent...@jhu.edu wrote:
 The RFC says yes on the author, no on the subject. The only things
 guaranteed are From: and originating timestamp. So I'm not sure why
 subject should be guaranteed a string result and not, say, Cc. 

Apologies -- I realize now you were talking about threads and not
messages, so I can't defer to RFCs. I still agree with the others, and
about how python users would deal with it. But I see your point better
now. Sorry to clutter.
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch


[PATCH] Fix old style notmuch-fcc-dirs configuration check.

2011-05-09 Thread Dmitry Kurochkin
In notmuch 0.5 notmuch-fcc-dirs style changed.  The previous code
did not correctly identify an old configuration and, as a
consequence, broke new configurations.

The fix was extracted from a bigger patch series by David
Edmondson id:1290682750-30283-2-git-send-email-...@dme.org.
---

The patch is for the release-candidate/0.6 branch.

Regards,
  Dmitry


 emacs/notmuch-maildir-fcc.el |2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/emacs/notmuch-maildir-fcc.el b/emacs/notmuch-maildir-fcc.el
index aede753..b6c6e2a 100644
--- a/emacs/notmuch-maildir-fcc.el
+++ b/emacs/notmuch-maildir-fcc.el
@@ -88,7 +88,7 @@ will NOT be removed or replaced.
   notmuch-fcc-dirs)
 
  ((and (listp notmuch-fcc-dirs)
-   (= 1 (length (car notmuch-fcc-dirs
+   (stringp (car notmuch-fcc-dirs)))
   ;; Old style - no longer works.
   (error Invalid `notmuch-fcc-dirs' setting (old style)))
 
-- 
1.7.5.1

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


Re: [PATCH] Fix old style notmuch-fcc-dirs configuration check.

2011-05-09 Thread Jameson Graef Rollins
On Mon,  9 May 2011 20:04:54 +0400, Dmitry Kurochkin 
dmitry.kuroch...@gmail.com wrote:
 In notmuch 0.5 notmuch-fcc-dirs style changed.  The previous code
 did not correctly identify an old configuration and, as a
 consequence, broke new configurations.
 
 The fix was extracted from a bigger patch series by David
 Edmondson id:1290682750-30283-2-git-send-email-...@dme.org.

Thanks for extracting the needed fix, Dmitry.  This makes things much
easier.  Applied to r-c/0.6

jamie.


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


Re: [PATCH] Use message-field-value instead of message-fetch-field in FCC header setup.

2011-05-09 Thread Jameson Graef Rollins
On Mon,  9 May 2011 16:06:20 +0400, Dmitry Kurochkin 
dmitry.kuroch...@gmail.com wrote:
 For message-fetch-field the buffer is expected to be narrowed to
 just the header of the message.  That is not the case when
 notmuch-fcc-header-setup is run, hence a wrong header value may be
 returned.  E.g. when forwarding an
 email, (message-fetch-field From) returns the From header value
 of the forwarded email.
 
 Message-field-value is the same as message-fetch-field, only
 narrows the buffer to the headers first.

Hey, Dmitry.  This is a nice clean fix.  I've applied it to the r-c/0.6.

jamie.


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


Re: release-candidate/0.6

2011-05-09 Thread James Vasile
On Sun, 08 May 2011 17:57:48 -0700, Jameson Graef Rollins 
jroll...@finestructure.net wrote:
 On Fri, 06 May 2011 19:56:30 -0400, James Vasile ja...@hackervisions.org 
 wrote:
  I sent two patches to the list on March 16.  They were a bug fix to
  allow notmuch to correctly handle some poorly formatted email.  Nobody
  ever replied, but I'd like to see the bug fixed nonetheless, as it
  results in unreadable mail.  Since I've actually seen such mail in the
  wild, I'd like to see Notmuch handle it.
 
 Hey, James.  Florian Friesdorf sent in a patch to sanitize the output of
 notmuch search, which I think is the issue that you're patches were also
 dealing with.  Florian's patch has be pushed to my
 release-candidate/0.6.  Can you see if your issue is fixed there?  If
 not maybe you could try submitting a new patch that would apply to the
 release-candidate/0.6 head.
 
 Thanks.

I'll take a look at it this week.  Thanks much.

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


Re: [PATCH] lib/message-file: plug three memleaks.

2011-05-09 Thread Jameson Graef Rollins
Hey, Anton.  Thanks for identifying and fixing these.  I've pushed this
to the r-c/0.6 branch.

jamie.


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


Re: release-candidate/0.6

2011-05-09 Thread Jameson Graef Rollins
Hi, folks.  I have pushed a couple of more patches to
release-candidate/0.6 [0]:

* Dmitry's fix for emacs fcc
* Anton Khirnov's memleak fixes

I think that everything else can wait for later releases.

***I hereby declare that release-candidate/0.6 is ready for release.***

I think the only remaining release tasks would be to update the NEWS
file, and then possibly debian/changelog if we want to expand the 0.6
entries a bit.

Carl: what do you think?  Are you willing to push this out as a new
release?  Please let me know if there's anything else I/we can do to
facilitate that.  Thanks!

jamie.

[0] git://finestructure.net/notmuch release-candidate/0.6
(commit id: 31b65daf40dbb5fd98a875452674fe6d1e5368db)


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


Re: vim support improvements for 0.6

2011-05-09 Thread Felipe Contreras
On Fri, May 6, 2011 at 10:51 PM, Jameson Graef Rollins
jroll...@finestructure.net wrote:
 Hi, Filipe.  I notice that you have been submitting a lot of patches for
 vim support.  As you may have seen, I'm trying to put together a release
 candidate for notmuch 0.6.  Since I know nothing about vim, would you be
 willing to prepare a patch set that includes all of the patches to vim
 support that you would like to see in the 0.6 release?

 I think the easiest way to do that would be for you to push a branch to
 your public repo that includes all of the vim improvements rebased on
 top of my release-candidate/0.6 branch.  If you can then point me to
 that branch, I can merge it with my release-candidate/0.6 branch and
 push it out for others to test.

 Let me know what you think.

All right. Hopefully nobody will request further changes to these patches:
git://github.com/felipec/notmuch.git [fc-vim-next]

It's not rebased on top of your branch, but there are no merge conflicts.

Cheers.

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


[PATCH] Don't re-compress .gz al. in notmuch-show-save-part.

2011-05-09 Thread Dmitry Kurochkin
Write-region handles some file names specially, see Emacs Lisp
manual section 25.11 Making Certain File Names Magic [1].  This
is a nice feature for normal text editing, but it is not
desirable if we need to save raw file content (e.g. attachment).
In particular, this affects archives and may result in corrupted
attachments saved with notmuch-show-save-part (attachment button
click handler).

Turns out, smart GNUS folks encountered the same problem and
implemented write-region wrapper which inhibits some file name
handlers.  In particular, this wrapper is used in mm-save-part,
which is why notmuch-save-attachments that uses it works fine
with archives.

The patch replaces write-region with mm-write-region in
notmuch-show-save-part.  Also it removes coding-system-for-write
and require-final-newline setting in notmuch-show-save-part.  The
former is set in mm-write-region.  The latter seems to be
unneeded because mm-save-part does not use it.

[1] http://www.gnu.org/s/emacs/manual/html_node/elisp/Magic-File-Names.html
---

This patch is for the release-candidate/0.6 branch.  I know
Jameson has declared it ready for release, but perhaps it is not
too late for a small fix?

Adding a test for this would be nice, but is a low priority for
me.  If anyone volunteers, that would be welcomed :)

Regards,
  Dmitry


 emacs/notmuch-show.el |9 +
 1 files changed, 5 insertions(+), 4 deletions(-)

diff --git a/emacs/notmuch-show.el b/emacs/notmuch-show.el
index 825988c..23291ce 100644
--- a/emacs/notmuch-show.el
+++ b/emacs/notmuch-show.el
@@ -306,10 +306,11 @@ message at DEPTH in the current thread.
   Filename to save as: 
   (or mailcap-download-directory ~/)
   nil nil
-  filename))
-   (require-final-newline nil)
-   (coding-system-for-write 'no-conversion))
-   (write-region (point-min) (point-max) file)
+  filename)))
+   ;; Don't re-compress .gz  al.  Arguably we should make
+   ;; `file-name-handler-alist' nil, but that would chop
+   ;; ange-ftp, which is reasonable to use here.
+   (mm-write-region (point-min) (point-max) file nil nil nil 
'no-conversion t)
 
 (defun notmuch-show-mm-display-part-inline (msg part content-type content)
   Use the mm-decode/mm-view functions to display a part in the
-- 
1.7.5.1

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


Re: [PATCH] python/thread: always return a string in get_subject/authors

2011-05-09 Thread Sebastian Spaeth
On Mon, 09 May 2011 09:20:41 -0300, David Bremner da...@tethera.net wrote:
 On Mon,  9 May 2011 09:06:34 +0200, Anton Khirnov an...@khirnov.net wrote:
  Now None is returned when those don't exist, which is inconvenient to
  deal with.
 
 I'm not using the python bindings, but from a philosophical point of
 view, this change makes me a bit uncomfortable since it apparently
 merges two cases together, and makes an error (no Subject)
 indistinguishable from an odd situation (Subject of empty string).
 Or am I missing something here?

Hi there,

This change makes me a bit uncomfortable too. 3 Reasons:

- I believe users should be able to distinguish the case when someone
  uses an empty subject, and when someone doesn't specify a subject at
  all.

- People have been writing code and breaking backwards compatability for
  such a small gain doesn't really seem worth it.

- Testing-wise this is easy. Just test for if subject: on the returned
  value and you'll get both cases (empty and non-existing).

But if people really want it, I won't object.

Sebastian


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


Re: [PATCH] python/thread: always return a string in get_subject/authors

2011-05-09 Thread Daniel Kahn Gillmor
On 05/09/2011 09:00 PM, Sebastian Spaeth wrote:
 On Mon, 09 May 2011 09:20:41 -0300, David Bremner da...@tethera.net wrote:
 On Mon,  9 May 2011 09:06:34 +0200, Anton Khirnov an...@khirnov.net wrote:
 Now None is returned when those don't exist, which is inconvenient to
 deal with.

 I'm not using the python bindings, but from a philosophical point of
 view, this change makes me a bit uncomfortable since it apparently
 merges two cases together, and makes an error (no Subject)
 indistinguishable from an odd situation (Subject of empty string).
 Or am I missing something here?
 
 This change makes me a bit uncomfortable too. 3 Reasons:
 
 - I believe users should be able to distinguish the case when someone
   uses an empty subject, and when someone doesn't specify a subject at
   all.

I'm going to me too! this sentiment as well.  Please do *not* conflate
no-subject with subject-is-empty-string.

If we leave them distinct, the caller is free to conflate them if they
want.  But if we conflate the two states first, there's no way for the
caller to differentiate between the two if they want to.

Thanks,

--dkg



signature.asc
Description: OpenPGP digital signature
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch


[PATCH] test: saving attachments from within emacs using notmuch-show-save-part

2011-05-09 Thread Dmitry Kurochkin
---
Oops, the previos
patch (id:1304990327-8665-1-git-send-email-dmitry.kuroch...@gmail.com)
has wrong title.

s/notmuch-show-save-attachments/notmuch-show-save-part/

Regards,
  Dmitry

 test/emacs |   14 +++---
 1 files changed, 11 insertions(+), 3 deletions(-)

diff --git a/test/emacs b/test/emacs
index 75dec89..675a887 100755
--- a/test/emacs
+++ b/test/emacs
@@ -112,9 +112,17 @@ Fcc: $(pwd)/mail/sent
 On Fri, 29 Mar 1974 10:00:00 -, Notmuch Test Suite 
test_su...@notmuchmail.org wrote:
  This is a test that messages are sent via SMTP
 
-test_begin_subtest Save attachment from within emacs
-echo ./attachment | test_emacs '(notmuch-show 
id:cf0c4d610911171136h1713aa59w9cf9aa31f052a...@mail.gmail.com) 
(notmuch-show-save-attachments)'  /dev/null 21
-output=$(cat attachment)
+test_begin_subtest Save attachment from within emacs using 
notmuch-show-save-attachments
+# save as archive to test that Emacs does not re-compress .gz
+echo ./attachment1.gz | test_emacs '(notmuch-show 
id:cf0c4d610911171136h1713aa59w9cf9aa31f052a...@mail.gmail.com) 
(notmuch-show-save-attachments)'  /dev/null 21
+output=$(cat attachment1.gz)
+expected=$(cat $EXPECTED/attachment)
+test_expect_equal $output $expected
+
+test_begin_subtest Save attachment from within emacs using 
notmuch-show-save-part
+# save as archive to test that Emacs does not re-compress .gz
+echo ./attachment2.gz | test_emacs '(notmuch-show-save-part 
id:cf0c4d610911171136h1713aa59w9cf9aa31f052a...@mail.gmail.com 5)'  
/dev/null 21
+output=$(cat attachment2.gz)
 expected=$(cat $EXPECTED/attachment)
 test_expect_equal $output $expected
 
-- 
1.7.5.1

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


[PATCH v2 0/2] test: add test for saving attachments using notmuch-show-save-part

2011-05-09 Thread Dmitry Kurochkin
This is amended patch from
id:1304990689-10933-1-git-send-email-dmitry.kuroch...@gmail.com
to test saving attachments withing Emacs using
notmuch-show-save-part.  It uses test_expect_equal_file instead
of test_expect_equal as suggested by Jameson.

This patch is for the release-candidate/0.6 branch.

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


[PATCH 1/2] test: copy files in test_expect_equal_file instead of moving them

2011-05-09 Thread Dmitry Kurochkin
Before the change, test_expect_equal_file moved files it compared
in case of failure.  The patch changes it to copy the files
instead.  This allows testing non-temporary files which are
stored in git.

Note: the change should not result in new temporary files left
after the tests.  Test_expect_equal_file used to move files only
on failure, so callers had to cleanup them anyway.
---
 test/test-lib.sh |4 ++--
 1 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/test/test-lib.sh b/test/test-lib.sh
index eaf5051..7cc43cd 100755
--- a/test/test-lib.sh
+++ b/test/test-lib.sh
@@ -477,8 +477,8 @@ test_expect_equal_file ()
test_ok_ $test_subtest_name
else
testname=$this_test.$test_count
-   mv $output $testname.output
-   mv $expected $testname.expected
+   cp $output $testname.output
+   cp $expected $testname.expected
test_failure_ $test_subtest_name $(diff -u 
$testname.expected $testname.output)
fi
 fi
-- 
1.7.5.1

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


[PATCH 2/2] test: add test for saving attachments using notmuch-show-save-part

2011-05-09 Thread Dmitry Kurochkin
Use .gz filenames for saved attachments in the tests to check
that Emacs does not re-compress the file.

Use test_expect_equal_file instead of test_expect_equal to avoid
binary output on the console.
---
 test/emacs |   14 +-
 1 files changed, 9 insertions(+), 5 deletions(-)

diff --git a/test/emacs b/test/emacs
index 75dec89..b376033 100755
--- a/test/emacs
+++ b/test/emacs
@@ -112,11 +112,15 @@ Fcc: $(pwd)/mail/sent
 On Fri, 29 Mar 1974 10:00:00 -, Notmuch Test Suite 
test_su...@notmuchmail.org wrote:
  This is a test that messages are sent via SMTP
 
-test_begin_subtest Save attachment from within emacs
-echo ./attachment | test_emacs '(notmuch-show 
id:cf0c4d610911171136h1713aa59w9cf9aa31f052a...@mail.gmail.com) 
(notmuch-show-save-attachments)'  /dev/null 21
-output=$(cat attachment)
-expected=$(cat $EXPECTED/attachment)
-test_expect_equal $output $expected
+test_begin_subtest Save attachment from within emacs using 
notmuch-show-save-attachments
+# save as archive to test that Emacs does not re-compress .gz
+echo ./attachment1.gz | test_emacs '(notmuch-show 
id:cf0c4d610911171136h1713aa59w9cf9aa31f052a...@mail.gmail.com) 
(notmuch-show-save-attachments)'  /dev/null 21
+test_expect_equal_file $EXPECTED/attachment attachment1.gz
+
+test_begin_subtest Save attachment from within emacs using 
notmuch-show-save-part
+# save as archive to test that Emacs does not re-compress .gz
+echo ./attachment2.gz | test_emacs '(notmuch-show-save-part 
id:cf0c4d610911171136h1713aa59w9cf9aa31f052a...@mail.gmail.com 5)'  
/dev/null 21
+test_expect_equal_file $EXPECTED/attachment attachment2.gz
 
 test_begin_subtest View raw message within emacs
 expected=$(cat $EXPECTED/raw-message-cf0c4d-52ad0a)
-- 
1.7.5.1

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


Re: [PATCH] test: add %s format string to all `message' calls in emacs tests

2011-05-09 Thread Austin Clements
This looks good to me (and is certainly more correct), but seems
rather roundabout.  Is there a reason this code doesn't simply (princ
(buffer-string))?

On Tue, May 10, 2011 at 1:40 AM, Dmitry Kurochkin
dmitry.kuroch...@gmail.com wrote:
 The patch replaces all (message (buffer-string)) calls in emacs
 tests with (message %s (buffer-string)).  This works around an
 Emacs (23.3+1-1 on current Debian Unstable) segfault in Ensure
 that emacs doesn't drop results test.  Note: the segfault does
 not happen on every test run.  Though, it seems to be
 consistently reproducible if the test uses 300 messages instead
 of 30.  Hopefully, it is the crash described in Emacs bug #8545
 [1] which is already fixed.

 Also, the patch makes the code more correct - we want to avoid
 accidentally interpreting '%' as format specifiers.

 [1] http://debbugs.gnu.org/cgi/bugreport.cgi?bug=8545
 ---

 The patch applies to the release-candidate/0.6 branch.

 Regards,
  Dmitry


  test/emacs                     |   18 +-
  test/emacs-large-search-buffer |    5 +++--
  2 files changed, 12 insertions(+), 11 deletions(-)

 diff --git a/test/emacs b/test/emacs
 index b376033..5b39423 100755
 --- a/test/emacs
 +++ b/test/emacs
 @@ -7,38 +7,38 @@ EXPECTED=../emacs.expected-output
  add_email_corpus

  test_begin_subtest Basic notmuch-hello view in emacs
 -output=$(test_emacs '(notmuch-hello) (message (buffer-string))' 21)
 +output=$(test_emacs '(notmuch-hello) (message %s (buffer-string))' 21)
  expected=$(cat $EXPECTED/notmuch-hello)
  test_expect_equal $output $expected

  test_begin_subtest Saved search with 0 results
 -output=$(test_emacs '(setq notmuch-show-empty-saved-searches t) (setq 
 notmuch-saved-searches '\''((inbox . tag:inbox) (unread . tag:unread) 
 (empty . tag:doesnotexist))) (notmuch-hello) (message (buffer-string))' 
 21)
 +output=$(test_emacs '(setq notmuch-show-empty-saved-searches t) (setq 
 notmuch-saved-searches '\''((inbox . tag:inbox) (unread . tag:unread) 
 (empty . tag:doesnotexist))) (notmuch-hello) (message %s 
 (buffer-string))' 21)
  expected=$(cat $EXPECTED/notmuch-hello-with-empty)
  test_expect_equal $output $expected

  test_begin_subtest No saved searches displayed (all with 0 results)
 -output=$(test_emacs '(setq notmuch-saved-searches '\''((empty . 
 tag:doesnotexist))) (notmuch-hello) (message (buffer-string))' 21)
 +output=$(test_emacs '(setq notmuch-saved-searches '\''((empty . 
 tag:doesnotexist))) (notmuch-hello) (message %s (buffer-string))' 21)
  expected=$(cat $EXPECTED/notmuch-hello-no-saved-searches)
  test_expect_equal $output $expected

  test_begin_subtest Basic notmuch-search view in emacs
 -output=$(test_emacs '(notmuch-search tag:inbox) (notmuch-test-wait) 
 (message (buffer-string))' 21)
 +output=$(test_emacs '(notmuch-search tag:inbox) (notmuch-test-wait) 
 (message %s (buffer-string))' 21)
  expected=$(cat $EXPECTED/notmuch-search-tag-inbox)
  test_expect_equal $output $expected

  test_begin_subtest Navigation of notmuch-hello to search results
 -output=$(test_emacs '(notmuch-hello) (goto-char (point-min)) 
 (re-search-forward inbox) (widget-button-press (point)) (notmuch-test-wait) 
 (message (buffer-string))' 21)
 +output=$(test_emacs '(notmuch-hello) (goto-char (point-min)) 
 (re-search-forward inbox) (widget-button-press (point)) (notmuch-test-wait) 
 (message %s (buffer-string))' 21)
  expected=$(cat $EXPECTED/notmuch-hello-view-inbox)
  test_expect_equal $output $expected

  test_begin_subtest Basic notmuch-show view in emacs
  maildir_storage_thread=$(notmuch search --output=threads 
 id:20091117190054.gu3...@dottiness.seas.harvard.edu)
 -output=$(test_emacs (notmuch-show \$maildir_storage_thread\) (message 
 (buffer-string)) 21)
 +output=$(test_emacs (notmuch-show \$maildir_storage_thread\) (message 
 \%s\ (buffer-string)) 21)
  expected=$(cat $EXPECTED/notmuch-show-thread-maildir-storage)
  test_expect_equal $output $expected

  test_begin_subtest Navigation of notmuch-search to thread view
 -output=$(test_emacs '(notmuch-search tag:inbox) (notmuch-test-wait) 
 (goto-char (point-min)) (re-search-forward Working with Maildir) 
 (notmuch-search-show-thread) (notmuch-test-wait) (message (buffer-string))' 
 21)
 +output=$(test_emacs '(notmuch-search tag:inbox) (notmuch-test-wait) 
 (goto-char (point-min)) (re-search-forward Working with Maildir) 
 (notmuch-search-show-thread) (notmuch-test-wait) (message %s 
 (buffer-string))' 21)
  test_expect_equal $output $expected

  test_begin_subtest Add tag from search view
 @@ -102,7 +102,7 @@ test_expect_equal $output thread:XXX   1974-03-29 
 [1/1] Notmuch Test Suite; T
  test_begin_subtest Reply within emacs
  # We sed away everything before the ^From in the output to avoid getting
  # confused by messages such as Parsing /home/cworth/.mailrc... done
 -output=$(test_emacs '(notmuch-search subject:\testing message sent via 
 SMTP\) (notmuch-test-wait) (notmuch-search-reply-to-thread) (message 
 (buffer-string))' 21 

Re: [PATCH] test: add %s format string to all `message' calls in emacs tests

2011-05-09 Thread Dmitry Kurochkin
On Tue, 10 May 2011 01:47:17 -0400, Austin Clements amdra...@mit.edu wrote:
 This looks good to me (and is certainly more correct), but seems
 rather roundabout.  Is there a reason this code doesn't simply (princ
 (buffer-string))?
 

Thanks, Austin!

I am, unfortunately, not an Emacs Lisp expert.  I did not know about
princ, so I improved what we had :) Princ seems to work fine.  And
certainly looks cleaner than using message and capturing stderr.  It
also fixes the segfault.

I will send another patch that uses princ instead of message.

Regards,
  Dmitry

 On Tue, May 10, 2011 at 1:40 AM, Dmitry Kurochkin
 dmitry.kuroch...@gmail.com wrote:
  The patch replaces all (message (buffer-string)) calls in emacs
  tests with (message %s (buffer-string)).  This works around an
  Emacs (23.3+1-1 on current Debian Unstable) segfault in Ensure
  that emacs doesn't drop results test.  Note: the segfault does
  not happen on every test run.  Though, it seems to be
  consistently reproducible if the test uses 300 messages instead
  of 30.  Hopefully, it is the crash described in Emacs bug #8545
  [1] which is already fixed.
 
  Also, the patch makes the code more correct - we want to avoid
  accidentally interpreting '%' as format specifiers.
 
  [1] http://debbugs.gnu.org/cgi/bugreport.cgi?bug=8545
  ---
 
  The patch applies to the release-candidate/0.6 branch.
 
  Regards,
   Dmitry
 
 
   test/emacs                     |   18 +-
   test/emacs-large-search-buffer |    5 +++--
   2 files changed, 12 insertions(+), 11 deletions(-)
 
  diff --git a/test/emacs b/test/emacs
  index b376033..5b39423 100755
  --- a/test/emacs
  +++ b/test/emacs
  @@ -7,38 +7,38 @@ EXPECTED=../emacs.expected-output
   add_email_corpus
 
   test_begin_subtest Basic notmuch-hello view in emacs
  -output=$(test_emacs '(notmuch-hello) (message (buffer-string))' 21)
  +output=$(test_emacs '(notmuch-hello) (message %s (buffer-string))' 21)
   expected=$(cat $EXPECTED/notmuch-hello)
   test_expect_equal $output $expected
 
   test_begin_subtest Saved search with 0 results
  -output=$(test_emacs '(setq notmuch-show-empty-saved-searches t) (setq 
  notmuch-saved-searches '\''((inbox . tag:inbox) (unread . 
  tag:unread) (empty . tag:doesnotexist))) (notmuch-hello) (message 
  (buffer-string))' 21)
  +output=$(test_emacs '(setq notmuch-show-empty-saved-searches t) (setq 
  notmuch-saved-searches '\''((inbox . tag:inbox) (unread . 
  tag:unread) (empty . tag:doesnotexist))) (notmuch-hello) (message 
  %s (buffer-string))' 21)
   expected=$(cat $EXPECTED/notmuch-hello-with-empty)
   test_expect_equal $output $expected
 
   test_begin_subtest No saved searches displayed (all with 0 results)
  -output=$(test_emacs '(setq notmuch-saved-searches '\''((empty . 
  tag:doesnotexist))) (notmuch-hello) (message (buffer-string))' 21)
  +output=$(test_emacs '(setq notmuch-saved-searches '\''((empty . 
  tag:doesnotexist))) (notmuch-hello) (message %s (buffer-string))' 21)
   expected=$(cat $EXPECTED/notmuch-hello-no-saved-searches)
   test_expect_equal $output $expected
 
   test_begin_subtest Basic notmuch-search view in emacs
  -output=$(test_emacs '(notmuch-search tag:inbox) (notmuch-test-wait) 
  (message (buffer-string))' 21)
  +output=$(test_emacs '(notmuch-search tag:inbox) (notmuch-test-wait) 
  (message %s (buffer-string))' 21)
   expected=$(cat $EXPECTED/notmuch-search-tag-inbox)
   test_expect_equal $output $expected
 
   test_begin_subtest Navigation of notmuch-hello to search results
  -output=$(test_emacs '(notmuch-hello) (goto-char (point-min)) 
  (re-search-forward inbox) (widget-button-press (point)) 
  (notmuch-test-wait) (message (buffer-string))' 21)
  +output=$(test_emacs '(notmuch-hello) (goto-char (point-min)) 
  (re-search-forward inbox) (widget-button-press (point)) 
  (notmuch-test-wait) (message %s (buffer-string))' 21)
   expected=$(cat $EXPECTED/notmuch-hello-view-inbox)
   test_expect_equal $output $expected
 
   test_begin_subtest Basic notmuch-show view in emacs
   maildir_storage_thread=$(notmuch search --output=threads 
  id:20091117190054.gu3...@dottiness.seas.harvard.edu)
  -output=$(test_emacs (notmuch-show \$maildir_storage_thread\) (message 
  (buffer-string)) 21)
  +output=$(test_emacs (notmuch-show \$maildir_storage_thread\) (message 
  \%s\ (buffer-string)) 21)
   expected=$(cat $EXPECTED/notmuch-show-thread-maildir-storage)
   test_expect_equal $output $expected
 
   test_begin_subtest Navigation of notmuch-search to thread view
  -output=$(test_emacs '(notmuch-search tag:inbox) (notmuch-test-wait) 
  (goto-char (point-min)) (re-search-forward Working with Maildir) 
  (notmuch-search-show-thread) (notmuch-test-wait) (message (buffer-string))' 
  21)
  +output=$(test_emacs '(notmuch-search tag:inbox) (notmuch-test-wait) 
  (goto-char (point-min)) (re-search-forward Working with Maildir) 
  (notmuch-search-show-thread) (notmuch-test-wait) (message %s 
  (buffer-string))' 21)
   test_expect_equal $output 

[PATCH] sanitize notmuch-search output - rewrapped

2011-05-09 Thread Florian Friesdorf
patch applies to current rc (ed6d3b8bb727b3acaa913945d6edf29843ab0864)
and works for me. It's the Andreas' patch just sent, that the commit
message will make it when applied with 'git am'.

Andreas Amann (1):
  Sanitize "Subject:" and "Author:" fields to not contain control
characters in notmuch-search

 notmuch-search.c |   22 --
 1 files changed, 20 insertions(+), 2 deletions(-)

-- 
1.7.5.1



[PATCH] Sanitize "Subject:" and "Author:" fields to not contain control characters in notmuch-search

2011-05-09 Thread Florian Friesdorf
On Sun, 8 May 2011 17:40:54 -0400, Austin Clements  wrote:
> Cool.  This seems very reasonable.
> 
> Just some style nits: The three places where you have
> "sanitize_string(", there should be a space between the function name
> and the paren.

fixed

> Relatedly, "for(;*loop;loop++){" should be spaced out
> like "for (; *loop; loop++) {".

fixed

> (..) 
> Also, existing code conventionally uses a variable named "local"
> for function-level talloc contexts such as your ctx_quote.

In notmuch-search.c there is no variable named "local", in the other
functions its also named ctx_quote. Should I rename all ctx_quote to
"local"?

Will send style fixes after we cleared this.

-- 
Florian Friesdorf 
  GPG FPR: 7A13 5EEE 1421 9FC2 108D  BAAF 38F8 99A3 0C45 F083
Jabber/XMPP: flo at chaoflow.net
IRC: chaoflow on freenode,ircnet,blafasel,OFTC
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 835 bytes
Desc: not available
URL: 



[PATCH] sanitize notmuch-search output - rewrapped

2011-05-09 Thread Florian Friesdorf
patch applies to current rc (ed6d3b8bb727b3acaa913945d6edf29843ab0864)
and works for me. It's the Andreas' patch just sent, that the commit
message will make it when applied with 'git am'.

Andreas Amann (1):
  Sanitize "Subject:" and "Author:" fields to not contain control
characters in notmuch-search

 notmuch-search.c |   22 --
 1 files changed, 20 insertions(+), 2 deletions(-)

-- 
1.7.5.1



[PATCH 1/2] style fixes

2011-05-09 Thread Florian Friesdorf
---
 notmuch-search.c |4 ++--
 1 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/notmuch-search.c b/notmuch-search.c
index e7fc41a..fd7c7d1 100644
--- a/notmuch-search.c
+++ b/notmuch-search.c
@@ -112,13 +112,13 @@ format_item_id_text (unused (const void *ctx),
 }

 static char *
-sanitize_string(const void *ctx, const char *str)
+sanitize_string (const void *ctx, const char *str)
 {
 char *out, *loop;

 loop = out = talloc_strdup (ctx, str);

-for(;*loop;loop++){
+for (; *loop; loop++) {
if ((unsigned char)(*loop) < 32)
*loop = '?';
 }
-- 
1.7.5.1



[PATCH 2/2] test for sanitized notmuch-search output

2011-05-09 Thread Florian Friesdorf
---
 test/corpus.ccs/cur/1:2, |8 
 test/search-output   |8 
 test/test-lib.sh |   12 
 3 files changed, 28 insertions(+), 0 deletions(-)
 create mode 100644 test/corpus.ccs/cur/1:2,

diff --git a/test/corpus.ccs/cur/1:2, b/test/corpus.ccs/cur/1:2,
new file mode 100644
index 000..60081c4
--- /dev/null
+++ b/test/corpus.ccs/cur/1:2,
@@ -0,0 +1,8 @@
+From: "Two =?ISO-8859-1?Q?line=0A_author?=" 
+To: notmuch at notmuchmail.org
+Date: Tue, 17 Nov 2009 21:28:37 +0600
+Subject: [notmuch] two =?ISO-8859-1?Q?line=0A_subject?=
+   headers
+Message-ID: <123>
+
+body
diff --git a/test/search-output b/test/search-output
index 33ae119..202c13e 100755
--- a/test/search-output
+++ b/test/search-output
@@ -316,4 +316,12 @@ cat  OUTPUT
+cat /dev/null
+cp -a ${MAIL_DIR} ../corpus.ccs.mail
+fi
+}
+
 test_begin_subtest ()
 {
 if [ -n "$inside_subtest" ]; then
-- 
1.7.5.1



[PATCH] sanitize notmuch-search output - rewrapped

2011-05-09 Thread Florian Friesdorf

this went out erroneously.

On Mon,  9 May 2011 01:12:19 +0200, Florian Friesdorf  
wrote:
> patch applies to current rc (ed6d3b8bb727b3acaa913945d6edf29843ab0864)
> and works for me. It's the Andreas' patch just sent, that the commit
> message will make it when applied with 'git am'.
> 
> Andreas Amann (1):
>   Sanitize "Subject:" and "Author:" fields to not contain control
> characters in notmuch-search
> 
>  notmuch-search.c |   22 --
>  1 files changed, 20 insertions(+), 2 deletions(-)
> 
> -- 
> 1.7.5.1
> 

-- 
Florian Friesdorf 
  GPG FPR: 7A13 5EEE 1421 9FC2 108D  BAAF 38F8 99A3 0C45 F083
Jabber/XMPP: flo at chaoflow.net
IRC: chaoflow on freenode,ircnet,blafasel,OFTC
-- 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/20110509/420d62cb/attachment.pgp>


release-candidate/0.6

2011-05-09 Thread Florian Friesdorf
On Sat, 07 May 2011 01:51:25 +0200, Florian Friesdorf  
wrote:
> (..)
> An open issue (also with gmime 2.4.24) is the extraction of a PDF from
> an encrypted message via emacs (discussed on irc before, mentioned here
> for completeness of the 

In the current release candidate this got fixed by Jamie.

-- 
Florian Friesdorf 
  GPG FPR: 7A13 5EEE 1421 9FC2 108D  BAAF 38F8 99A3 0C45 F083
Jabber/XMPP: flo at chaoflow.net
IRC: chaoflow on freenode,ircnet,blafasel,OFTC
-- 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/20110509/1a3cc788/attachment.pgp>


[PATCH] lib/message-file: plug three memleaks.

2011-05-09 Thread Anton Khirnov
On Fri, 15 Apr 2011 16:43:58 +0200, Anton Khirnov  wrote:
> ---
>  lib/message-file.c |5 +
>  1 files changed, 5 insertions(+), 0 deletions(-)
> 
> diff --git a/lib/message-file.c b/lib/message-file.c
> index 7722832..b7b3286 100644
> --- a/lib/message-file.c
> +++ b/lib/message-file.c
> @@ -341,12 +341,17 @@ notmuch_message_file_get_header (notmuch_message_file_t 
> *message,
>   strncpy(combined_header,header_sofar,hdrsofar);
>   *(combined_header+hdrsofar) = ' ';
>   strncpy(combined_header+hdrsofar+1,decoded_value,newhdr+1);
> + free(decoded_value);
>   g_hash_table_insert (message->headers, header, combined_header);
>   }
>   } else {
>   if (header_sofar == NULL) {
>   /* Only insert if we don't have a value for this header, yet. */
>   g_hash_table_insert (message->headers, header, decoded_value);
> + } else {
> + free(header);
> + free(decoded_value);
> + decoded_value = header_sofar;
>   }
>   }
>   /* if we found a match we can bail - unless of course we are
> -- 
> 1.7.4.1
> 
> ___
> notmuch mailing list
> notmuch at notmuchmail.org
> http://notmuchmail.org/mailman/listinfo/notmuch

ping

--
Anton Khirnov


[PATCH] python/thread: always return a string in get_subject/authors

2011-05-09 Thread Anton Khirnov
Now None is returned when those don't exist, which is inconvenient to
deal with.
---
 bindings/python/notmuch/thread.py |6 --
 1 files changed, 4 insertions(+), 2 deletions(-)

diff --git a/bindings/python/notmuch/thread.py 
b/bindings/python/notmuch/thread.py
index eebd6cb..cf26957 100644
--- a/bindings/python/notmuch/thread.py
+++ b/bindings/python/notmuch/thread.py
@@ -281,7 +281,8 @@ class Thread(object):
 """
 if self._thread is None:
 raise NotmuchError(STATUS.NOT_INITIALIZED)
-return Thread._get_authors(self._thread)
+ret = Thread._get_authors(self._thread)
+return ret if ret else ''

 def get_subject(self):
 """Returns the Subject of 'thread'
@@ -291,7 +292,8 @@ class Thread(object):
 """
 if self._thread is None:
 raise NotmuchError(STATUS.NOT_INITIALIZED)
-return Thread._get_subject(self._thread)
+ret = Thread._get_subject(self._thread)
+return ret if ret else ''

 def get_newest_date(self):
 """Returns time_t of the newest message date
-- 
1.7.4.4



[PATCH] Use message-field-value instead of message-fetch-field in FCC header setup.

2011-05-09 Thread Dmitry Kurochkin
For message-fetch-field the buffer is expected to be narrowed to
just the header of the message.  That is not the case when
notmuch-fcc-header-setup is run, hence a wrong header value may be
returned.  E.g. when forwarding an
email, (message-fetch-field "From") returns the From header value
of the forwarded email.

Message-field-value is the same as message-fetch-field, only
narrows the buffer to the headers first.
---

The patch is for the release-candidate/0.6 branch.  It is an amended
version of a patch I sent a while ago
id:"1278000507-22290-4-git-send-email-dmitry.kurochkin at gmail.com".

Regards,
  Dmitry


 emacs/notmuch-maildir-fcc.el |6 +++---
 1 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/emacs/notmuch-maildir-fcc.el b/emacs/notmuch-maildir-fcc.el
index 3f1c124..aede753 100644
--- a/emacs/notmuch-maildir-fcc.el
+++ b/emacs/notmuch-maildir-fcc.el
@@ -80,7 +80,7 @@ will NOT be removed or replaced."
   (let ((subdir
 (cond
  ((or (not notmuch-fcc-dirs)
-  (message-fetch-field "Fcc"))
+  (message-field-value "Fcc"))
   ;; Nothing set or an existing header.
   nil)

@@ -93,7 +93,7 @@ will NOT be removed or replaced."
   (error "Invalid `notmuch-fcc-dirs' setting (old style)"))

  ((listp notmuch-fcc-dirs)
-  (let* ((from (message-fetch-field "From"))
+  (let* ((from (message-field-value "From"))
  (match
   (catch 'first-match
 (dolist (re-folder notmuch-fcc-dirs)
@@ -118,7 +118,7 @@ will NOT be removed or replaced."
  (concat (notmuch-database-path) "/" subdir)

   ;; finally test if fcc points to a valid maildir
-  (let ((fcc-header (message-fetch-field "Fcc")))
+  (let ((fcc-header (message-field-value "Fcc")))
(unless (notmuch-maildir-fcc-dir-is-maildir-p fcc-header)
  (cond ((not (file-writable-p fcc-header))
 (error (format "No permission to create %s, which does not 
exist"
-- 
1.7.5.1



[PATCH] python/thread: always return a string in get_subject/authors

2011-05-09 Thread Austin Clements
Your commit message is inconsistent with your change; is your intent to
return None or the empty string?  Also, could you modify your commit message
to say what "those" are?
On May 9, 2011 3:06 AM, "Anton Khirnov"  wrote:
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://notmuchmail.org/pipermail/notmuch/attachments/20110509/c70fe8b1/attachment.html>


[PATCH] python/thread: always return a string in get_subject/authors

2011-05-09 Thread David Bremner
On Mon,  9 May 2011 09:06:34 +0200, Anton Khirnov  wrote:
> Now None is returned when those don't exist, which is inconvenient to
> deal with.

I'm not using the python bindings, but from a philosophical point of
view, this change makes me a bit uncomfortable since it apparently
merges two cases together, and makes an error (no Subject)
indistinguishable from an odd situation (Subject of empty string).
Or am I missing something here?

All the best,

David


[PATCH] lib/message-file: plug three memleaks.

2011-05-09 Thread Austin Clements
Cool.  This looks like a pretty nasty leak and I'm pretty sure your
patch is correct (though it took me a while to convince myself!).

My one nit is code style.  There should be a space between the
function name and the paren.  (Oddly, the is_received handling that
you changed is the only place in notmuch where I've seen this style
violated; but there's no sense in spreading this inconsistency.)

On Mon, May 9, 2011 at 2:46 AM, Anton Khirnov  wrote:
> On Fri, 15 Apr 2011 16:43:58 +0200, Anton Khirnov  
> wrote:
>> ---
>> ?lib/message-file.c | ? ?5 +
>> ?1 files changed, 5 insertions(+), 0 deletions(-)
>>
>> diff --git a/lib/message-file.c b/lib/message-file.c
>> index 7722832..b7b3286 100644
>> --- a/lib/message-file.c
>> +++ b/lib/message-file.c
>> @@ -341,12 +341,17 @@ notmuch_message_file_get_header 
>> (notmuch_message_file_t *message,
>> ? ? ? ? ? ? ? strncpy(combined_header,header_sofar,hdrsofar);
>> ? ? ? ? ? ? ? *(combined_header+hdrsofar) = ' ';
>> ? ? ? ? ? ? ? strncpy(combined_header+hdrsofar+1,decoded_value,newhdr+1);
>> + ? ? ? ? ? ? free(decoded_value);
>> ? ? ? ? ? ? ? g_hash_table_insert (message->headers, header, 
>> combined_header);
>> ? ? ? ? ? }
>> ? ? ? } else {
>> ? ? ? ? ? if (header_sofar == NULL) {
>> ? ? ? ? ? ? ? /* Only insert if we don't have a value for this header, yet. 
>> */
>> ? ? ? ? ? ? ? g_hash_table_insert (message->headers, header, decoded_value);
>> + ? ? ? ? } else {
>> + ? ? ? ? ? ? free(header);
>> + ? ? ? ? ? ? free(decoded_value);
>> + ? ? ? ? ? ? decoded_value = header_sofar;
>> ? ? ? ? ? }
>> ? ? ? }
>> ? ? ? /* if we found a match we can bail - unless of course we are
>> --
>> 1.7.4.1
>>
>> ___
>> notmuch mailing list
>> notmuch at notmuchmail.org
>> http://notmuchmail.org/mailman/listinfo/notmuch
>
> ping
>
> --
> Anton Khirnov
> ___
> notmuch mailing list
> notmuch at notmuchmail.org
> http://notmuchmail.org/mailman/listinfo/notmuch
>


[PATCH] python/thread: always return a string in get_subject/authors

2011-05-09 Thread servilio
On 9 May 2011 08:20, David Bremner  wrote:
> On Mon, ?9 May 2011 09:06:34 +0200, Anton Khirnov  
> wrote:
>> Now None is returned when those don't exist, which is inconvenient to
>> deal with.
>
> I'm not using the python bindings, but from a philosophical point of
> view, this change makes me a bit uncomfortable since it apparently
> merges two cases together, and makes an error (no Subject)
> indistinguishable from an odd situation (Subject of empty string).
> Or am I missing something here?

I see the the same issue.

Servilio


release-candidate/0.6

2011-05-09 Thread micah anderson
On Fri, 06 May 2011 12:46:34 -0700, Jameson Graef Rollins  wrote:
>
> I might try to add a couple of more things before declaring the
> candidate release-ready, but this is more-or-less it.  Please start
> using this branch "in production" as much as possible, so that we can
> build up a chorus of support for pushing this release out.  Once you
> have build, tested, and started using the branch, please reply to this
> email thread to express your support for it's release.

I've been using this branch now for a couple of days and its solid,
thanks for pulling this together Mr. Rollins.

> The release-candidate/0.6 branch also includes debian package updates,
> so you should be able to easily build debian packages from the branch:
> 
> git buildpackage -uc -us --git-ignore-branch

I used this mechanism to build a package and install it, it worked
well. I also ran lintian on it just to see if there were any issues, but
you get an A+.

micah
-- 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/20110509/a99fc56d/attachment.pgp>


[PATCH] python/thread: always return a string in get_subject/authors

2011-05-09 Thread Anton Khirnov
On Mon, 09 May 2011 09:20:41 -0300, David Bremner  wrote:
> On Mon,  9 May 2011 09:06:34 +0200, Anton Khirnov  
> wrote:
> > Now None is returned when those don't exist, which is inconvenient to
> > deal with.
> 
> I'm not using the python bindings, but from a philosophical point of
> view, this change makes me a bit uncomfortable since it apparently
> merges two cases together, and makes an error (no Subject)
> indistinguishable from an odd situation (Subject of empty string).
> Or am I missing something here?

The question is whether this is really a problem.

For a single message, it might make sense to distinguish between 'no
header' and 'empty header'.

But those aren't message headers, those are thread properties. And I'd
argue that a thread always has authors and a subject (possibly empty).

--
Anton Khirnov


[PATCH] lib/message-file: plug three memleaks.

2011-05-09 Thread Anton Khirnov
---
 lib/message-file.c |5 +
 1 files changed, 5 insertions(+), 0 deletions(-)

diff --git a/lib/message-file.c b/lib/message-file.c
index 7722832..99505c1 100644
--- a/lib/message-file.c
+++ b/lib/message-file.c
@@ -341,12 +341,17 @@ notmuch_message_file_get_header (notmuch_message_file_t 
*message,
strncpy(combined_header,header_sofar,hdrsofar);
*(combined_header+hdrsofar) = ' ';
strncpy(combined_header+hdrsofar+1,decoded_value,newhdr+1);
+   free (decoded_value);
g_hash_table_insert (message->headers, header, combined_header);
}
} else {
if (header_sofar == NULL) {
/* Only insert if we don't have a value for this header, yet. */
g_hash_table_insert (message->headers, header, decoded_value);
+   } else {
+   free (header);
+   free (decoded_value);
+   decoded_value = header_sofar;
}
}
/* if we found a match we can bail - unless of course we are
-- 
1.7.5.1



[PATCH] python/thread: always return a string in get_subject/authors

2011-05-09 Thread Jesse Rosenthal
On Mon, 09 May 2011 17:13:10 +0200, Anton Khirnov  wrote:
> But those aren't message headers, those are thread properties. And I'd
> argue that a thread always has authors and a subject (possibly empty).

The RFC says yes on the author, no on the subject. The only things
guaranteed are "From:" and originating timestamp. So I'm not sure why
subject should be guaranteed a string result and not, say, "Cc." 

My sense is that Python users are prety good with testing against None,
especially since (not "") == (not []) == (not None) == True. This change
seems like it would end up producing more inconsistencies with the way
you deal with headers, by producing special cases.

--Jesse


[PATCH] python/thread: always return a string in get_subject/authors

2011-05-09 Thread Jesse Rosenthal

On Mon, 09 May 2011 11:23:16 -0400, Jesse Rosenthal  
wrote:
> The RFC says yes on the author, no on the subject. The only things
> guaranteed are "From:" and originating timestamp. So I'm not sure why
> subject should be guaranteed a string result and not, say, "Cc." 

Apologies -- I realize now you were talking about threads and not
messages, so I can't defer to RFCs. I still agree with the others, and
about how python users would deal with it. But I see your point better
now. Sorry to clutter.


[PATCH] Fix old style notmuch-fcc-dirs configuration check.

2011-05-09 Thread Dmitry Kurochkin
In notmuch 0.5 notmuch-fcc-dirs style changed.  The previous code
did not correctly identify an old configuration and, as a
consequence, broke new configurations.

The fix was extracted from a bigger patch series by David
Edmondson id:"1290682750-30283-2-git-send-email-dme at dme.org".
---

The patch is for the release-candidate/0.6 branch.

Regards,
  Dmitry


 emacs/notmuch-maildir-fcc.el |2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/emacs/notmuch-maildir-fcc.el b/emacs/notmuch-maildir-fcc.el
index aede753..b6c6e2a 100644
--- a/emacs/notmuch-maildir-fcc.el
+++ b/emacs/notmuch-maildir-fcc.el
@@ -88,7 +88,7 @@ will NOT be removed or replaced."
   notmuch-fcc-dirs)

  ((and (listp notmuch-fcc-dirs)
-   (= 1 (length (car notmuch-fcc-dirs
+   (stringp (car notmuch-fcc-dirs)))
   ;; Old style - no longer works.
   (error "Invalid `notmuch-fcc-dirs' setting (old style)"))

-- 
1.7.5.1



[PATCH] Fix old style notmuch-fcc-dirs configuration check.

2011-05-09 Thread Jameson Graef Rollins
On Mon,  9 May 2011 20:04:54 +0400, Dmitry Kurochkin  wrote:
> In notmuch 0.5 notmuch-fcc-dirs style changed.  The previous code
> did not correctly identify an old configuration and, as a
> consequence, broke new configurations.
> 
> The fix was extracted from a bigger patch series by David
> Edmondson id:"1290682750-30283-2-git-send-email-dme at dme.org".

Thanks for extracting the needed fix, Dmitry.  This makes things much
easier.  Applied to r-c/0.6

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/20110509/7e361d49/attachment.pgp>


[PATCH] Use message-field-value instead of message-fetch-field in FCC header setup.

2011-05-09 Thread Jameson Graef Rollins
On Mon,  9 May 2011 16:06:20 +0400, Dmitry Kurochkin  wrote:
> For message-fetch-field the buffer is expected to be narrowed to
> just the header of the message.  That is not the case when
> notmuch-fcc-header-setup is run, hence a wrong header value may be
> returned.  E.g. when forwarding an
> email, (message-fetch-field "From") returns the From header value
> of the forwarded email.
> 
> Message-field-value is the same as message-fetch-field, only
> narrows the buffer to the headers first.

Hey, Dmitry.  This is a nice clean fix.  I've applied it to the r-c/0.6.

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/20110509/f0a2268a/attachment.pgp>


release-candidate/0.6

2011-05-09 Thread James Vasile
On Sun, 08 May 2011 17:57:48 -0700, Jameson Graef Rollins  wrote:
> On Fri, 06 May 2011 19:56:30 -0400, James Vasile  
> wrote:
> > I sent two patches to the list on March 16.  They were a bug fix to
> > allow notmuch to correctly handle some poorly formatted email.  Nobody
> > ever replied, but I'd like to see the bug fixed nonetheless, as it
> > results in unreadable mail.  Since I've actually seen such mail in the
> > wild, I'd like to see Notmuch handle it.
> 
> Hey, James.  Florian Friesdorf sent in a patch to sanitize the output of
> notmuch search, which I think is the issue that you're patches were also
> dealing with.  Florian's patch has be pushed to my
> release-candidate/0.6.  Can you see if your issue is fixed there?  If
> not maybe you could try submitting a new patch that would apply to the
> release-candidate/0.6 head.
> 
> Thanks.

I'll take a look at it this week.  Thanks much.



[PATCH] lib/message-file: plug three memleaks.

2011-05-09 Thread Jameson Graef Rollins
Hey, Anton.  Thanks for identifying and fixing these.  I've pushed this
to the r-c/0.6 branch.

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/20110509/cd5f561d/attachment.pgp>


release-candidate/0.6

2011-05-09 Thread Jameson Graef Rollins
Hi, folks.  I have pushed a couple of more patches to
release-candidate/0.6 [0]:

* Dmitry's fix for emacs fcc
* Anton Khirnov's memleak fixes

I think that everything else can wait for later releases.

***I hereby declare that release-candidate/0.6 is ready for release.***

I think the only remaining release tasks would be to update the NEWS
file, and then possibly debian/changelog if we want to expand the 0.6
entries a bit.

Carl: what do you think?  Are you willing to push this out as a new
release?  Please let me know if there's anything else I/we can do to
facilitate that.  Thanks!

jamie.

[0] git://finestructure.net/notmuch release-candidate/0.6
(commit id: 31b65daf40dbb5fd98a875452674fe6d1e5368db)
-- 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/20110509/e2a6e77d/attachment.pgp>


[PATCH] python/thread: always return a string in get_subject/authors

2011-05-09 Thread Daniel Kahn Gillmor
On 05/09/2011 09:00 PM, Sebastian Spaeth wrote:
> On Mon, 09 May 2011 09:20:41 -0300, David Bremner  
> wrote:
>> On Mon,  9 May 2011 09:06:34 +0200, Anton Khirnov  
>> wrote:
>>> Now None is returned when those don't exist, which is inconvenient to
>>> deal with.
>>
>> I'm not using the python bindings, but from a philosophical point of
>> view, this change makes me a bit uncomfortable since it apparently
>> merges two cases together, and makes an error (no Subject)
>> indistinguishable from an odd situation (Subject of empty string).
>> Or am I missing something here?
> 
> This change makes me a bit uncomfortable too. 3 Reasons:
> 
> - I believe users should be able to distinguish the case when someone
>   uses an empty subject, and when someone doesn't specify a subject at
>   all.

I'm going to "me too!" this sentiment as well.  Please do *not* conflate
no-subject with subject-is-empty-string.

If we leave them distinct, the caller is free to conflate them if they
want.  But if we conflate the two states first, there's no way for the
caller to differentiate between the two if they want to.

Thanks,

--dkg

-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 1030 bytes
Desc: OpenPGP digital signature
URL: 
<http://notmuchmail.org/pipermail/notmuch/attachments/20110509/6eaa6210/attachment.pgp>