On Mon, 04 Jul 2011 23:36:35 +0200, Matthieu Lemerre ra...@free.fr wrote:
I like to use the space (and sometimes the backspace key) to read
threads back and forth, but sometimes I might read stuff to quickly and
archive a thread without wanting it. It is then complex to find it back
On Fri, 1 Jul 2011 13:13:27 -0700 (PDT), notmuch-commits-sender at
notmuchmail.org (David Bremner) wrote:
> The annotated tag, 0.6 has been created
> at 6eae40d57f12bb44d1b375a1d37454974f6dafd2 (tag)
>tagging 6bd02fb4dbee9e0fc372661af573a2ac380fed8a (commit)
> replaces 0.6rc1
>
On Fri, 01 Jul 2011 09:26:48 +1200, Michael Hudson-Doyle wrote:
> On Wed, 29 Jun 2011 22:40:07 -0700, Carl Worth wrote:
> Non-text part: multipart/mixed
> Non-text part: multipart/signed
>
> not sure why notmuch reply is putting that there :)
They shouldn't be, and I sent a patch to fix that a
On Fri, 01 Jul 2011 09:26:48 +1200, Michael Hudson-Doyle
michael.hud...@canonical.com wrote:
On Wed, 29 Jun 2011 22:40:07 -0700, Carl Worth cwo...@cworth.org wrote:
Non-text part: multipart/mixed
Non-text part: multipart/signed
not sure why notmuch reply is putting that there :)
They
On Thu, 30 Jun 2011 13:04:23 +1000, Brian May wrote:
> Are there any keyboard bindings to go forwards to the next message or
> backwards to the last message without marking anything as archived?
'n' and 'p'. These are documented in the notmuch-show mode help ('?'
while in notmuch-show mode).
On Wed, 29 Jun 2011 14:21:11 -0600, Mark Anderson wrote:
> I personally prefer --output=files remain as it was, with one file per
> mail (even though I submitted the patch to change it). I suggest that
> we could add another format to supply all files (perhaps
> --output=allfiles, or
On Wed, 29 Jun 2011 20:42:01 +0100, Robin Green wrote:
> It's really dangerous to use the 'a' key in notmuch-mode in an inbox
> thread which has multiple unread replies! Yes, the other unread replies
> will still be tagged unread, but the user might not immediately be aware
> of them. It would be
On Tue, 28 Jun 2011 07:31:31 +, Jani Nikula wrote:
> Add a pseudo saved search that matches all the mail that no other saved
> search matches. Add new customization option notmuch-saved-searches-nomatch
> to enable and name the pseudo saved search.
Hi, Jani. I haven't looked too closely at
This test was not properly documented when it was originally added (my
bad).
---
test/README |7 +++
1 files changed, 7 insertions(+), 0 deletions(-)
diff --git a/test/README b/test/README
index 8fbf78d..f9ac607 100644
--- a/test/README
+++ b/test/README
@@ -156,6 +156,13 @@ library for
This test was not properly documented when it was originally added (my
bad).
---
test/README |7 +++
1 files changed, 7 insertions(+), 0 deletions(-)
diff --git a/test/README b/test/README
index 8fbf78d..f9ac607 100644
--- a/test/README
+++ b/test/README
@@ -156,6 +156,13 @@ library for
On Tue, 28 Jun 2011 07:31:31 +, Jani Nikula j...@nikula.org wrote:
Add a pseudo saved search that matches all the mail that no other saved
search matches. Add new customization option notmuch-saved-searches-nomatch
to enable and name the pseudo saved search.
Hi, Jani. I haven't looked too
On Wed, 29 Jun 2011 20:42:01 +0100, Robin Green gree...@greenrd.org wrote:
It's really dangerous to use the 'a' key in notmuch-mode in an inbox
thread which has multiple unread replies! Yes, the other unread replies
will still be tagged unread, but the user might not immediately be aware
of
On Wed, 29 Jun 2011 20:15:22 +, Jani Nikula j...@nikula.org wrote:
So to clarify, do you prefer having on/off switches, or just enabling
this without customization at all? Personally I'd shy away from the
latter, but I guess it depends on how useful vs. distracting people find
this.
My
On Wed, 22 Jun 2011 22:26:06 -0300, David Bremner wrote:
> 3) Cherry-pick/merge a small number of _important_ [2] bug fixes between now
>and July 1.
Hi, David. You might want to consider applying the following patches
for 0.6:
Bug fix for raw output of gmime parts:
On Thu, 23 Jun 2011 16:33:18 -0700, Carl Worth wrote:
> I'd like to investigate this case a little bit to help answer the
> question of whether "notmuch should have done anything in this case".
Hi, Carl. You can see this error if you try to output raw a multipart/*
or message/rfc822 part, ie:
On Thu, 23 Jun 2011 16:33:18 -0700, Carl Worth cwo...@cworth.org wrote:
I'd like to investigate this case a little bit to help answer the
question of whether notmuch should have done anything in this case.
Hi, Carl. You can see this error if you try to output raw a multipart/*
or
On Wed, 22 Jun 2011 22:26:06 -0300, David Bremner da...@tethera.net wrote:
3) Cherry-pick/merge a small number of _important_ [2] bug fixes between now
and July 1.
Hi, David. You might want to consider applying the following patches
for 0.6:
Bug fix for raw output of gmime parts:
On Mon, 27 Jun 2011 16:43:36 -0400, Austin Clements amdra...@mit.edu wrote:
Just to clarify my understanding, --format=raw is only intended to
work on either the whole message (special-cased in do_show_single) or
a leaf MIME part, and in any other case, it will output nothing? The
raw output
On Sat, 25 Jun 2011 23:18:52 +0100, Robin Green wrote:
> A race condition in the '*' command was noted when it was first
> proposed. It looks to me like it still exists - has anything been done
> about it?
Hi, Robin. Can you explain what you mean by the "'*' command"? Are you
referring to '*'
On Sat, 25 Jun 2011 23:18:52 +0100, Robin Green gree...@greenrd.org wrote:
A race condition in the '*' command was noted when it was first
proposed. It looks to me like it still exists - has anything been done
about it?
Hi, Robin. Can you explain what you mean by the '*' command? Are you
Hey, folks. As of today I am for some reason no longer able to build
the Notmuch Debian package. I'm using the same build technique I have
been using for a while (git-buildpackage). The tail of the failing
build log is pasted at the bottom of this message. Is anyone else
encountering anything
On Thu, 23 Jun 2011 09:13:05 +0200, Sebastian Spaeth sebast...@sspaeth.de
wrote:
Me bows to the tyrant and the hard-working henchmen. :)
We (henchmen) generally prefer to go by the official title of
Interim Distinguished co-Chief Vice Tyrant.
jamie.
pgp6gQsY9ndfp.pgp
Description: PGP
This is patch is a temporary work-around for a slight regression that
popped up in the part handling reorganization. Currently, text/plain
parts are always preferred, if present, over other non-text/plain
parts in multipart/alternative. However, this means that if there is
a blank text/plain
I think we just agreed with cworth on irc that this simple patch will
satisfy his regression worry for 0.6. Meaning that we can push out
the release after this patch is merged.
bremner, our new "Release Tyrant", has his finger on the trigger...
This is patch is a temporary work-around for a slight regression that
popped up in the part handling reorganization. Currently, text/plain
parts are always preferred, if present, over other non-text/plain
parts in multipart/alternative. However, this means that if there is
a blank text/plain
---
debian/control | 12 +---
1 files changed, 9 insertions(+), 3 deletions(-)
diff --git a/debian/control b/debian/control
index 90bd0ee..3289282 100644
--- a/debian/control
+++ b/debian/control
@@ -6,9 +6,15 @@ Uploaders:
martin f. krafft ,
Jameson Graef Rollins ,
David Bremner
-Uploaders: martin f. krafft ,
- Jameson Graef Rollins ,
- David Bremner
+Uploaders:
+ martin f. krafft ,
+ Jameson Graef Rollins ,
+ David Bremner ,
Build-Depends: debhelper (>= 7.0.50~), pkg-config, libxapian-dev,
libgmime-2.4-dev, libtalloc-dev, libz-dev, emacs23-nox,
pyt
hrm, sorry. Looks like those last two patches got a little messed up.
These two patches replace the previous two.
jamie.
---
debian/control |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/debian/control b/debian/control
index 49f6961..52c2e5a 100644
--- a/debian/control
+++ b/debian/control
@@ -15,7 +15,7 @@ Build-Depends:
libz-dev,
emacs23 | emacs23-nox,
python-all (>= 2.6.6-3~),
---
debian/control |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/debian/control b/debian/control
index 0c998df..49f6961 100644
--- a/debian/control
+++ b/debian/control
@@ -13,7 +13,7 @@ Build-Depends:
libgmime-2.4-dev,
libtalloc-dev,
libz-dev,
- emacs23-nox,
+
:
- martin f. krafft ,
+ martin f. krafft ,
Jameson Graef Rollins ,
David Bremner ,
-Build-Depends: debhelper (>= 7.0.50~), pkg-config, libxapian-dev,
- libgmime-2.4-dev, libtalloc-dev, libz-dev, emacs23-nox,
- python-all (>= 2.6.6-3~)
+Build-Depends:
+ debhelper (>= 7.0.50~),
+ p
-Uploaders: martin f. krafft ,
- Jameson Graef Rollins ,
- David Bremner
+Uploaders:
+ martin f. krafft ,
+ Jameson Graef Rollins ,
+ David Bremner ,
Build-Depends: debhelper (>= 7.0.50~), pkg-config, libxapian-dev,
libgmime-2.4-dev, libtalloc-dev, libz-dev, emacs23-nox,
pyt
---
debian/control |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/debian/control b/debian/control
index 49f6961..52c2e5a 100644
--- a/debian/control
+++ b/debian/control
@@ -15,7 +15,7 @@ Build-Depends:
libz-dev,
emacs23 | emacs23-nox,
python-all (= 2.6.6-3~),
...@debian.org
Uploaders:
- martin f. krafft madd...@debian.org,
+ martin f. krafft madd...@debian.org,
Jameson Graef Rollins jroll...@finestructure.net,
David Bremner brem...@debian.org,
-Build-Depends: debhelper (= 7.0.50~), pkg-config, libxapian-dev,
- libgmime-2.4-dev, libtalloc-dev, libz-dev
...@debian.org
-Uploaders: martin f. krafft madd...@debian.org,
- Jameson Graef Rollins jroll...@finestructure.net,
- David Bremner brem...@debian.org
+Uploaders:
+ martin f. krafft madd...@debian.org,
+ Jameson Graef Rollins jroll...@finestructure.net,
+ David Bremner brem
---
debian/control |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/debian/control b/debian/control
index 0c998df..49f6961 100644
--- a/debian/control
+++ b/debian/control
@@ -13,7 +13,7 @@ Build-Depends:
libgmime-2.4-dev,
libtalloc-dev,
libz-dev,
- emacs23-nox,
+
hrm, sorry. Looks like those last two patches got a little messed up.
These two patches replace the previous two.
jamie.
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch
...@debian.org
-Uploaders: martin f. krafft madd...@debian.org,
- Jameson Graef Rollins jroll...@finestructure.net,
- David Bremner brem...@debian.org
+Uploaders:
+ martin f. krafft madd...@debian.org,
+ Jameson Graef Rollins jroll...@finestructure.net,
+ David Bremner brem
---
debian/control | 12 +---
1 files changed, 9 insertions(+), 3 deletions(-)
diff --git a/debian/control b/debian/control
index 90bd0ee..3289282 100644
--- a/debian/control
+++ b/debian/control
@@ -6,9 +6,15 @@ Uploaders:
martin f. krafft madd...@debian.org,
Jameson Graef Rollins
On Tue, 21 Jun 2011 02:01:17 +0200, Sebastien Binet
wrote:
> and I checked there were no lingering .el files...
>
> so...
> any way to tell which notmuch-emacs-ui I am actually using ? (I am a newbie
> when comes to hacking lisp)
Hey, Sebastien. You can determine the loaded version of a
On Mon, 20 Jun 2011 18:43:01 +0200, Sebastien Binet
wrote:
> > You didn't try forwarding the email to the list ;)
> ah! that easy, heh ?
>
Attachment:
1300323326_0.6276.farnsworth,U=250482,FMD5=af1cd994dfcb9286c394d142687ff5a0:2,S
(application/octet-stream)
Hi, Sebastien. I don't seem to
On Mon, 20 Jun 2011 18:43:01 +0200, Sebastien Binet
wrote:
> > You didn't try forwarding the email to the list ;)
> ah! that easy, heh ?
>
> Attachment:
> 1300323326_0.6276.farnsworth,U=250482,FMD5=af1cd994dfcb9286c394d142687ff5a0:2,S
> (application/octet-stream)
Are you sure this is the
On Mon, 20 Jun 2011 17:52:03 +0200, Sebastien Binet
wrote:
> it is only when the signature is lumped like below, that I get the error:
> [ 4-line signature. Click/Enter to show. ]
>
> also, it's only happening to the last message of a thread.
Ah, ok. Have you tried looking at the raw
On Mon, 20 Jun 2011 09:15:06 +0200, Sebastien Binet
wrote:
> recently, using the head of notmuch-git:
>
> git://notmuchmail.org/git/notmuch
>
> when a mail ends with an url and is recognized as a signature:
...
> I can't hit [space] to go to the next thread and I get the following
> error:
>
On Mon, 20 Jun 2011 18:43:01 +0200, Sebastien Binet seb.bi...@gmail.com wrote:
You didn't try forwarding the email to the list ;)
ah! that easy, heh ?
Attachment:
1300323326_0.6276.farnsworth,U=250482,FMD5=af1cd994dfcb9286c394d142687ff5a0:2,S
(application/octet-stream)
Are you sure this
Maintainer: Carl Worth
Uploaders: Jameson Graef Rollins , martin f.
krafft
-Build-Depends: debhelper (>= 7.0.50~), pkg-config, libxapian-dev,
- libgmime-2.4-dev, libtalloc-dev, libz-dev, emacs (>= 23~),
- python-all (>= 2.6.6-3~)
+Build-Depends:
+ debhelper (>= 7.0.50~),
+ pkg-config,
Maintainer: Carl Worth cwo...@debian.org
Uploaders: Jameson Graef Rollins jroll...@finestructure.net, martin f.
krafft madd...@debian.org
-Build-Depends: debhelper (= 7.0.50~), pkg-config, libxapian-dev,
- libgmime-2.4-dev, libtalloc-dev, libz-dev, emacs (= 23~),
- python-all (= 2.6.6-3~)
+Build
On Wed, 15 Jun 2011 18:25:14 +0400, Dmitry Kurochkin wrote:
> I know you prefer tests to go before patches and I agree with that. But
> most of the time I do tests after coding. I do not know an easy way to
> reorder patches in git. (Also I do not know how to amend an old patch,
> wish more
On Tue, 31 May 2011 10:07:13 -0700, Jameson Graef Rollins wrote:
> This adds two callback functions to the sigstatus button. If the sig
> status is "good", then clicking the button displays the output of "gpg
> --list-keys" on the key fingerprint. If the sigsta
On Tue, 31 May 2011 10:07:13 -0700, Jameson Graef Rollins
jroll...@finestructure.net wrote:
This adds two callback functions to the sigstatus button. If the sig
status is good, then clicking the button displays the output of gpg
--list-keys on the key fingerprint. If the sigstatus is bad
On Wed, 15 Jun 2011 18:25:14 +0400, Dmitry Kurochkin
dmitry.kuroch...@gmail.com wrote:
I know you prefer tests to go before patches and I agree with that. But
most of the time I do tests after coding. I do not know an easy way to
reorder patches in git. (Also I do not know how to amend an
On Tue, 14 Jun 2011 21:58:48 +0530, "Aneesh Kumar K.V" wrote:
> Lars Kellogg-Stedman - 2009-11-17
> |-> Mikhail Gusarov - 2009-11-17
> |-> Lars Kellogg-Stedman - 2009-11-17
> |->"Mikhail Gusarov" - 2009-11-17
> |->"Keith Packard" - 2009-11-17
Or better yet:
?? Lars
On Tue, 14 Jun 2011 21:58:48 +0530, Aneesh Kumar K.V
aneesh.ku...@linux.vnet.ibm.com wrote:
Lars Kellogg-Stedman l...@seas.harvard.edu - 2009-11-17
|- Mikhail Gusarov dotted...@dottedmag.net - 2009-11-17
|- Lars Kellogg-Stedman l...@seas.harvard.edu - 2009-11-17
|-Mikhail Gusarov
The quoted text doesn't need to mention that the message being replied
to had these crufty parts.
---
notmuch-reply.c |5 +
1 files changed, 5 insertions(+), 0 deletions(-)
diff --git a/notmuch-reply.c b/notmuch-reply.c
index 7a76ba3..0eb295e 100644
--- a/notmuch-reply.c
+++
In reply, the quoted text does not need to mention that the original
message had "application/pgp-signed" or "application/pgp-encrypted"
parts.
---
test/crypto|2 --
test/multipart |1 -
2 files changed, 0 insertions(+), 3 deletions(-)
diff --git a/test/crypto b/test/crypto
index
These lines are just cruft in this case, and can be removed.
---
notmuch-reply.c | 11 ++-
1 files changed, 6 insertions(+), 5 deletions(-)
diff --git a/notmuch-reply.c b/notmuch-reply.c
index a19eb19..7a76ba3 100644
--- a/notmuch-reply.c
+++ b/notmuch-reply.c
@@ -93,7 +93,12 @@
There's no reason to output "Non-text part:" lines for parts that are
not leaf nodes, eg. multipart/* and message/rfc822. We fix the text
here to test for their absence. The next patch will fix reply
accordingly.
---
test/multipart |3 ---
1 files changed, 0 insertions(+), 3 deletions(-)
This is a small set of tweaks to remove unneccessary "Non-text part:"
lines in reply, for parts that really don't need to be mentioned.
This patch set is not really related to the series that it is being
sent in reply to, but it has been worked on top of the message/rfc822
rework of the multipart
On Mon, 06 Jun 2011 13:20:00 -0400, Jesse Rosenthal
wrote:
> After a conversation with David last year about bug-tracking, I worked
> up a rough python-based prototype of this. It worked in terms of
> namespaces, so Carl could associate the namespace "public" with a list
> of tags he publishes
On Mon, 06 Jun 2011 13:20:00 -0400, Jesse Rosenthal jrosent...@jhu.edu wrote:
After a conversation with David last year about bug-tracking, I worked
up a rough python-based prototype of this. It worked in terms of
namespaces, so Carl could associate the namespace public with a list
of tags he
The quoted text doesn't need to mention that the message being replied
to had these crufty parts.
---
notmuch-reply.c |5 +
1 files changed, 5 insertions(+), 0 deletions(-)
diff --git a/notmuch-reply.c b/notmuch-reply.c
index 7a76ba3..0eb295e 100644
--- a/notmuch-reply.c
+++
These lines are just cruft in this case, and can be removed.
---
notmuch-reply.c | 11 ++-
1 files changed, 6 insertions(+), 5 deletions(-)
diff --git a/notmuch-reply.c b/notmuch-reply.c
index a19eb19..7a76ba3 100644
--- a/notmuch-reply.c
+++ b/notmuch-reply.c
@@ -93,7 +93,12 @@
In reply, the quoted text does not need to mention that the original
message had application/pgp-signed or application/pgp-encrypted
parts.
---
test/crypto|2 --
test/multipart |1 -
2 files changed, 0 insertions(+), 3 deletions(-)
diff --git a/test/crypto b/test/crypto
index
On Fri, 03 Jun 2011 15:56:42 -0700, Carl Worth wrote:
> Frankly, I wouldn't mind doing strict time-based releases with something
> like the following:
Hi, Carl. I think this is a fine idea, and we (not you) can definitely
run this process. I'm quite sure that at least bremner and I can
On Fri, 03 Jun 2011 15:56:42 -0700, Carl Worth cwo...@cworth.org wrote:
Frankly, I wouldn't mind doing strict time-based releases with something
like the following:
Hi, Carl. I think this is a fine idea, and we (not you) can definitely
run this process. I'm quite sure that at least bremner
On Mon, 06 Jun 2011 05:17:27 -0700, Carl Worth wrote:
> Hopefully, someone will provide me with a good way to publish my queue
> soon, ("notmuch search --output=html" ?), and then communication like
> this will be a bit easier. ;-)
I've been thinking about this more and it really seems we need a
On Mon, 06 Jun 2011 05:17:27 -0700, Carl Worth cwo...@cworth.org wrote:
Hopefully, someone will provide me with a good way to publish my queue
soon, (notmuch search --output=html ?), and then communication like
this will be a bit easier. ;-)
I've been thinking about this more and it really
Here's the gmime bug about returning rfc822 messages as GMimeObjects:
https://bugzilla.gnome.org/show_bug.cgi?id=651964
jamie.
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 835 bytes
Desc: not available
On Fri, 03 Jun 2011 18:27:42 -0700, Carl Worth wrote:
> From a quick rebase of your release-candidate branch and a comparison
> with what I have queued it looks like only the following commits are
> left on your branch and not in my email queue:
>
> emacs: update notmuch-crypto-process-mime
I forgot to mention that this patch series (well the last patch in
particular) supersedes the previous emacs rfc822 part handling patch I
sent in:
id:"1307034386-6107-1-git-send-email-jrollins at finestructure.net"
jamie.
-- next part --
A non-text attachment was
The insert-part-message/rfc822 function is overhauled to properly
processes the new formatting of message/rfc822 parts. The json output
for message parts now includes "headers" and "body" fields, which are
now parsed and output appropriately.
---
emacs/notmuch-show.el | 21
This new function takes a GMimeMessage as input, and outputs the
formatted headers. This allows for message/rfc822 parts to be
formatted on output in a similar way to full messages (see previous
patch that overhauls the multipart test for more info).
---
notmuch-client.h |1 +
The main goal of this overhaul is to define how message/rfc822 parts
should be handled. message/rfc822 parts should be output in a similar
fashion to the outer message, including some subset of the rfc822
headers. The following decisions about formatting of message/rfc822
parts were made:
The
The test message date, "Tue, 05 Jan 2001 15:43:57 -", is not
actually a real date. 05 Jan 2001 was in fact a Friday, not a
Tuesday. Date parsers (such as "date" in coreutils) will return "Fri"
as the day for this string, even if "Tue" is specified.
Also, the time zone "-" is actually
There were two "--format=text --part=0" tests. One of them was
supposed to be a test for "--format=text --part=1".
There were also two errant "test_expect_equal_file OUTPUT EXPECTED"
lines, that are removed here.
---
test/multipart | 17 ++---
1 files changed, 2 insertions(+), 15
So the following patch series is my attempt to improve handling of
message/rfc822 parts. The first couple of patches fix/overhaul the
multipart test, and the last two improve the message/rfc822 part
output and emacs handling, respectively.
The fix outputs the rfc822 message in a format similar
This new function takes a GMimeMessage as input, and outputs the
formatted headers. This allows for message/rfc822 parts to be
formatted on output in a similar way to full messages (see previous
patch that overhauls the multipart test for more info).
---
notmuch-client.h |1 +
The insert-part-message/rfc822 function is overhauled to properly
processes the new formatting of message/rfc822 parts. The json output
for message parts now includes headers and body fields, which are
now parsed and output appropriately.
---
emacs/notmuch-show.el | 21 +
1
The test message date, Tue, 05 Jan 2001 15:43:57 -, is not
actually a real date. 05 Jan 2001 was in fact a Friday, not a
Tuesday. Date parsers (such as date in coreutils) will return Fri
as the day for this string, even if Tue is specified.
Also, the time zone - is actually always
So the following patch series is my attempt to improve handling of
message/rfc822 parts. The first couple of patches fix/overhaul the
multipart test, and the last two improve the message/rfc822 part
output and emacs handling, respectively.
The fix outputs the rfc822 message in a format similar
There were two --format=text --part=0 tests. One of them was
supposed to be a test for --format=text --part=1.
There were also two errant test_expect_equal_file OUTPUT EXPECTED
lines, that are removed here.
---
test/multipart | 17 ++---
1 files changed, 2 insertions(+), 15
The main goal of this overhaul is to define how message/rfc822 parts
should be handled. message/rfc822 parts should be output in a similar
fashion to the outer message, including some subset of the rfc822
headers. The following decisions about formatting of message/rfc822
parts were made:
The
I forgot to mention that this patch series (well the last patch in
particular) supersedes the previous emacs rfc822 part handling patch I
sent in:
id:1307034386-6107-1-git-send-email-jroll...@finestructure.net
jamie.
pgpMyp64jKP3K.pgp
Description: PGP signature
On Fri, 03 Jun 2011 18:27:42 -0700, Carl Worth cwo...@cworth.org wrote:
From a quick rebase of your release-candidate branch and a comparison
with what I have queued it looks like only the following commits are
left on your branch and not in my email queue:
emacs: update
Here's the gmime bug about returning rfc822 messages as GMimeObjects:
https://bugzilla.gnome.org/show_bug.cgi?id=651964
jamie.
pgpqPmrMDqcxr.pgp
Description: PGP signature
___
notmuch mailing list
notmuch@notmuchmail.org
On Fri, 03 Jun 2011 15:38:29 -0700, Carl Worth wrote:
> commit d5b4d950245605b84c56ce991fa3c59a073a70e5
> Author: Jameson Graef Rollins
> Date: Sat May 28 14:52:00 2011 -0700
>
> show: Avoid inadvertently closing stdout
>
> GMime has a nasty habit of taking
On Fri, 03 Jun 2011 12:56:50 -0700, Carl Worth wrote:
> Otherwise, the patches up to this point in the thread have all either
> been pushed or I've asked for some additional information (perhaps
> that's just this patch and the "old style fcc dirs" patch?).
Great! That's really great news,
On Fri, 03 Jun 2011 12:56:50 -0700, Carl Worth wrote:
> On Sat, 28 May 2011 14:52:00 -0700, Jameson Graef Rollins finestructure.net> wrote:
> > The declaration of the GMimeStream pointer to stdout in
> > format_part_content_text was somehow preventing subsequent printf
> &g
This was a minor oversite in checking of part type when outputing
content raw. This was causing gmime was to throw an exception to
stderr.
Unfortunately the gmime exception was not being caught by notmuch, or
the test suite. I'm not sure if notmuch should have done anything in
this case, but
On Fri, 03 Jun 2011 12:56:50 -0700, Carl Worth cwo...@cworth.org wrote:
On Sat, 28 May 2011 14:52:00 -0700, Jameson Graef Rollins
jroll...@finestructure.net wrote:
The declaration of the GMimeStream pointer to stdout in
format_part_content_text was somehow preventing subsequent printf
On Fri, 03 Jun 2011 12:56:50 -0700, Carl Worth cwo...@cworth.org wrote:
Otherwise, the patches up to this point in the thread have all either
been pushed or I've asked for some additional information (perhaps
that's just this patch and the old style fcc dirs patch?).
Great! That's really
On Fri, 03 Jun 2011 15:38:29 -0700, Carl Worth cwo...@cworth.org wrote:
commit d5b4d950245605b84c56ce991fa3c59a073a70e5
Author: Jameson Graef Rollins jroll...@finestructure.net
Date: Sat May 28 14:52:00 2011 -0700
show: Avoid inadvertently closing stdout
GMime has a nasty
On Thu, 02 Jun 2011 18:49:22 +0200, Felix Geller wrote:
> Jeff replied and sent me a working patch :) Not sure yet how he prefers
> to publish the patch, but the problem is fixed.
That's great! What did Jeff say exactly? Is the patch to gmime 2.4?
Did he mention that he was including them in
Hey, folks. I've been noticing a couple of issues with message/rfc822
part handling in recent builds of notmuch/master. They are rooted in
the new part handling rework that was done recently. I just want to
mention them here, to make people aware of them, until we get a chance
to address them.
After the recent part-handling overhaul, emacs handling of
message/rfc822 parts broke, not outputting the message contents. This
"fixes" then handling as is, but there are still problems with how
notmuch is outputting message parts that needs to be addressed (for
instance, message headers are not
This was a minor oversite in checking of part type when outputing
content raw. This was causing gmime was to throw an exception to
stderr.
Unfortunately the gmime exception was not being caught by notmuch, or
the test suite. I'm not sure if notmuch should have done anything in
this case, but
On Tue, 31 May 2011 19:33:29 +0200, Felix Geller wrote:
> I get the following trace when using show --decrypt to decrypt a
> specific message (have to kill the process to actually get the trace):
>
> #0 0x0001006121a6 in poll ()
> #1 0x00010006d3d2 in gpg_ctx_op_step ()
> #2
On Tue, 31 May 2011 19:33:29 +0200, Felix Geller fgel...@gmail.com wrote:
I get the following trace when using show --decrypt to decrypt a
specific message (have to kill the process to actually get the trace):
#0 0x0001006121a6 in poll ()
#1 0x00010006d3d2 in gpg_ctx_op_step ()
#2
This was a minor oversite in checking of part type when outputing
content raw. This was causing gmime was to throw an exception to
stderr.
Unfortunately the gmime exception was not being caught by notmuch, or
the test suite. I'm not sure if notmuch should have done anything in
this case, but
After the recent part-handling overhaul, emacs handling of
message/rfc822 parts broke, not outputting the message contents. This
fixes then handling as is, but there are still problems with how
notmuch is outputting message parts that needs to be addressed (for
instance, message headers are not
1301 - 1400 of 1627 matches
Mail list logo
