[PATCH] python/thread: always return a string in get_subject/authors
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.
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
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
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] python/thread: always return a string in get_subject/authors
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
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
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.
---
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
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
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.
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] Use message-field-value instead of message-fetch-field in FCC header setup.
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
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.
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
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
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.
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
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
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
--- 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
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
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
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
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
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
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
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
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
---
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
--- 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 @@ catOUTPUT +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
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
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.
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
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.
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
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
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.
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
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
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
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.
---
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
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
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.
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.
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.
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
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.
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
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
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>
