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
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
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:
___
notmuch mailing list
notmuch@
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 to
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
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 u
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
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 chang
---
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
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
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 y
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
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
> Edm
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
> e
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
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
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 remain
On Fri, May 6, 2011 at 10:51 PM, Jameson Graef Rollins
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 t
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 res
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 chang
---
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
wrote:
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,
---
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
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 bran
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_equa
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
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
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
wrote:
> The patch replaces all (message (buffer-string)) calls in emacs
> tests with (message
On Tue, 10 May 2011 01:47:17 -0400, Austin Clements 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 k
The patch replaces all (message (buffer-string)) calls in emacs
tests with (princ (buffer-string)). This avoids accidentally
interpreting '%' as format specifiers and makes code simpler
because we do not need to capture stderr.
Also, the patch works around an Emacs (23.3+1-1 on current Debian
Uns
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 notmuc
---
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 *
-
---
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
le
Type: application/pgp-signature
Size: 835 bytes
Desc: not available
URL:
<http://notmuchmail.org/pipermail/notmuch/attachments/20110509/420d62cb/attachment.pgp>
gp-signature
Size: 835 bytes
Desc: not available
URL:
<http://notmuchmail.org/pipermail/notmuch/attachments/20110509/1a3cc788/attachment.pgp>
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
> @@
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
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
achment was scrubbed...
URL:
<http://notmuchmail.org/pipermail/notmuch/attachments/20110509/c70fe8b1/attachment.html>
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 to
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
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 bi
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://notmuch
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 ch
---
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
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
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
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 pat
e: application/pgp-signature
Size: 835 bytes
Desc: not available
URL:
<http://notmuchmail.org/pipermail/notmuch/attachments/20110509/7e361d49/attachment.pgp>
'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>
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'
mail.org/pipermail/notmuch/attachments/20110509/cd5f561d/attachment.pgp>
ble
URL:
<http://notmuchmail.org/pipermail/notmuch/attachments/20110509/e2a6e77d/attachment.pgp>
tiate 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>
54 matches
Mail list logo
