[PATCH] fix sum moar typos
Hi Pieter, On Sat, 4 Jun 2011 17:54:12 +0200, Pieter Praet wrote: > Because they cause global warming. > > Signed-off-by: Pieter Praet > --- > > TL;DR: Various typo fixes. Applies to jrollins/release-candidate/0.6 > (2baf08f5) > > Due to the impending 0.6 release, I've gone off on an ephemeral typo hunt, > and have brought back some trophies. > > As it's such an utterly amusing passtime, I've been pretty fat-fingered about > it, > and wouldn't be surprised if I've missed some, or even made some new ones. > > Nonetheless: Lets maek 0.6 purrfec! Yaeh ! /Xavier P.S: good job !
improving message/rfc822 part handling
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 URL: <http://notmuchmail.org/pipermail/notmuch/attachments/20110605/d622ef65/attachment.pgp>
release-candidate/0.6 redux
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 config variable documentation. Hey, Carl. This is actually a five-patch series that starts at: emacs: add notmuch-show-refresh-view function id:"1306627784-3401-1-git-send-email-jrollins at finestructure.net" You should also look at the following two patch series to fix the message/rfc822 part handling: Do not attept to output part raw if part is not GMimePart. id:"1307120466-4980-1-git-send-email-jrollins at finestructure.net" improving message/rfc822 part handling id:"1307320169-29905-1-git-send-email-jrollins at finestructure.net" 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/20110605/a3b71c95/attachment.pgp>
improving message/rfc822 part handling
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 scrubbed... Name: not available Type: application/pgp-signature Size: 835 bytes Desc: not available URL: <http://notmuchmail.org/pipermail/notmuch/attachments/20110605/4864e94f/attachment.pgp>
[PATCH 5/5] emacs: Improve support for message/rfc822 parts.
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 files changed, 13 insertions(+), 8 deletions(-)
diff --git a/emacs/notmuch-show.el b/emacs/notmuch-show.el
index 7d848e3..0f1fe69 100644
--- a/emacs/notmuch-show.el
+++ b/emacs/notmuch-show.el
@@ -519,21 +519,26 @@ current buffer, if possible."
t)
(defun notmuch-show-insert-part-message/rfc822 (msg part content-type nth
depth declared-type)
- (let* ((message-part (plist-get part :content))
-(inner-parts (plist-get message-part :content)))
-(notmuch-show-insert-part-header nth declared-type content-type nil)
+ (notmuch-show-insert-part-header nth declared-type content-type nil)
+ (let* ((message (car (plist-get part :content)))
+(headers (plist-get message :headers))
+(body (car (plist-get message :body)))
+(start (point)))
+
;; Override `notmuch-message-headers' to force `From' to be
;; displayed.
(let ((notmuch-message-headers '("From" "Subject" "To" "Cc" "Date")))
- (notmuch-show-insert-headers (plist-get part :headers)))
+ (notmuch-show-insert-headers (plist-get message :headers)))
+
;; Blank line after headers to be compatible with the normal
;; message display.
(insert "\n")
-;; Show all of the parts.
-(mapc (lambda (inner-part)
- (notmuch-show-insert-bodypart msg inner-part depth))
- inner-parts))
+;; Show the body
+(notmuch-show-insert-bodypart msg body depth)
+
+(when notmuch-show-indent-multipart
+ (indent-rigidly start (point) 1)))
t)
(defun notmuch-show-insert-part-text/plain (msg part content-type nth depth
declared-type)
--
1.7.4.4
[PATCH 4/5] Improve handling of message/rfc822 parts by adding a new header_message_part function to the formating structure.
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 +
notmuch-reply.c | 31 ++-
notmuch-show.c | 88 ++---
show-message.c | 12 +++
4 files changed, 119 insertions(+), 13 deletions(-)
diff --git a/notmuch-client.h b/notmuch-client.h
index 63be337..b50cb38 100644
--- a/notmuch-client.h
+++ b/notmuch-client.h
@@ -63,6 +63,7 @@ typedef struct notmuch_show_format {
const char *header_start;
void (*header) (const void *ctx,
notmuch_message_t *message);
+void (*header_message_part) (GMimeMessage *message);
const char *header_end;
const char *body_start;
void (*part_start) (GMimeObject *part,
diff --git a/notmuch-reply.c b/notmuch-reply.c
index 514bbc6..a19eb19 100644
--- a/notmuch-reply.c
+++ b/notmuch-reply.c
@@ -25,12 +25,15 @@
#include "gmime-filter-headers.h"
static void
+reply_headers_message_part (GMimeMessage *message);
+
+static void
reply_part_content (GMimeObject *part);
static const notmuch_show_format_t format_reply = {
"",
"", NULL,
- "", NULL, "",
+ "", NULL, reply_headers_message_part, ">\n",
"",
NULL,
NULL,
@@ -63,6 +66,28 @@ show_reply_headers (GMimeMessage *message)
}
static void
+reply_headers_message_part (GMimeMessage *message)
+{
+InternetAddressList *recipients;
+const char *recipients_string;
+
+printf ("> From: %s\n", g_mime_message_get_sender (message));
+recipients = g_mime_message_get_recipients (message,
GMIME_RECIPIENT_TYPE_TO);
+recipients_string = internet_address_list_to_string (recipients, 0);
+if (recipients_string)
+ printf ("> To: %s\n",
+ recipients_string);
+recipients = g_mime_message_get_recipients (message,
GMIME_RECIPIENT_TYPE_CC);
+recipients_string = internet_address_list_to_string (recipients, 0);
+if (recipients_string)
+ printf ("> Cc: %s\n",
+ recipients_string);
+printf ("> Subject: %s\n", g_mime_message_get_subject (message));
+printf ("> Date: %s\n", g_mime_message_get_date_as_string (message));
+}
+
+
+static void
reply_part_content (GMimeObject *part)
{
GMimeContentType *content_type = g_mime_object_get_content_type
(GMIME_OBJECT (part));
@@ -95,6 +120,10 @@ reply_part_content (GMimeObject *part)
if (stream_stdout)
g_object_unref(stream_stdout);
}
+else if (g_mime_content_type_is_type (content_type, "message", "rfc822"))
+{
+ /* Output nothing, since rfc822 subparts will be handled individually.
*/
+}
else
{
if (disposition &&
diff --git a/notmuch-show.c b/notmuch-show.c
index 0e9d00d..6e2e560 100644
--- a/notmuch-show.c
+++ b/notmuch-show.c
@@ -29,6 +29,9 @@ format_headers_text (const void *ctx,
notmuch_message_t *message);
static void
+format_headers_message_part_text (GMimeMessage *message);
+
+static void
format_part_start_text (GMimeObject *part,
int *part_count);
@@ -41,7 +44,7 @@ format_part_end_text (GMimeObject *part);
static const notmuch_show_format_t format_text = {
"",
"\fmessage{ ", format_message_text,
- "\fheader{\n", format_headers_text, "\fheader}\n",
+ "\fheader{\n", format_headers_text,
format_headers_message_part_text, "\fheader}\n",
"\fbody{\n",
format_part_start_text,
NULL,
@@ -63,6 +66,9 @@ format_headers_json (const void *ctx,
notmuch_message_t *message);
static void
+format_headers_message_part_json (GMimeMessage *message);
+
+static void
format_part_start_json (unused (GMimeObject *part),
int *part_count);
@@ -81,7 +87,7 @@ format_part_end_json (GMimeObject *part);
static const notmuch_show_format_t format_json = {
"[",
"{", format_message_json,
- ", \"headers\": {", format_headers_json, "}",
+ "\"headers\": {", format_headers_json,
format_headers_message_part_json, "}",
", \"body\": [",
format_part_start_json,
format_part_encstatus_json,
@@ -102,7 +108,7 @@ format_message_mbox (const void *ctx,
static const notmuch_show_format_t format_mbox = {
"",
"", format_message_mbox,
-"", NULL, "",
+"", NULL, NULL, "",
"",
NULL,
NULL,
@@ -121,7 +127,7 @@ format_part_content_raw (GMimeObject *part);
static const notmuch_show_format_t format_raw = {
"",
"", NULL,
- "", NULL, "",
+ "", NULL, format_headers_message_part_text, "\n",
"",
NULL,
[PATCH 3/5] test: overhaul multipart test to test for improved message/rfc822 handling
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 format and content of message/rfc822 parts shall be as similar as
possible to that of full messages. In particular, for formatted
outputs, the "content" of rfc822 part output should include "headers"
and "body" fields).
The "body" field shall include the body of the message.
The "headers" field shall include the following headers, since these
are the ones available from the GMimeMessage:
"From"
"To"
"Cc"
"Subject"
"Date"
However, for the case of --format=raw the raw rfc822 should be output,
including all headers.
A subset of relevant headers shall be output in reply.
The test embedded rfc822 message is also modified to be itself
multipart, so we can more fully test how all sub parts of the message
part are output.
---
test/multipart | 368 +++-
1 files changed, 283 insertions(+), 85 deletions(-)
diff --git a/test/multipart b/test/multipart
index 67e04d9..95577dc 100755
--- a/test/multipart
+++ b/test/multipart
@@ -2,6 +2,29 @@
test_description="output of multipart message"
. ./test-lib.sh
+cat < embedded_message
+From: Carl Worth
+To: cworth at cworth.org
+Subject: html message
+Date: Fri, 05 Jan 2001 15:42:57 +
+User-Agent: Notmuch/0.5 (http://notmuchmail.org) Emacs/23.3.1
(i486-pc-linux-gnu)
+Message-ID: <87liy5ap01.fsf at yoom.home.cworth.org>
+MIME-Version: 1.0
+Content-Type: multipart/alternative; boundary="==-=-=="
+
+--==-=-==
+Content-Type: text/html
+
+This is an embedded message, with a multipart/alternative part.
+
+--==-=-==
+Content-Type: text/plain
+
+This is an embedded message, with a multipart/alternative part.
+
+--==-=-==--
+EOF
+
cat < ${MAIL_DIR}/multipart
From: Carl Worth
To: cworth at cworth.org
@@ -20,17 +43,9 @@ Content-Type: multipart/mixed; boundary="=-=-="
Content-Type: message/rfc822
Content-Disposition: inline
-From: Carl Worth
-To: cworth at cworth.org
-Subject: html message
-Date: Fri, 05 Jan 2001 15:42:57 +
-User-Agent: Notmuch/0.5 (http://notmuchmail.org) Emacs/23.3.1
(i486-pc-linux-gnu)
-Message-ID: <87liy5ap01.fsf at yoom.home.cworth.org>
-MIME-Version: 1.0
-Content-Type: text/html
-
-This is an embedded message, with a single html part.
-
+EOF
+cat embedded_message >> ${MAIL_DIR}/multipart
+cat <> ${MAIL_DIR}/multipart
--=-=-=
Content-Disposition: attachment; filename=attachment
@@ -106,21 +121,34 @@ Date: Fri, 05 Jan 2001 15:43:57 +
part{ ID: 1, Content-type: multipart/signed
part{ ID: 2, Content-type: multipart/mixed
part{ ID: 3, Content-type: message/rfc822
- part{ ID: 4, Content-type: text/html
+ header{
+From: Carl Worth
+To: cworth at cworth.org
+Subject: html message
+Date: Fri, 05 Jan 2001 15:42:57 +
+ header}
+ body{
+ part{ ID: 4, Content-type: multipart/alternative
+ part{ ID: 5, Content-type: text/html
Non-text part: text/html
part}
+ part{ ID: 6, Content-type: text/plain
+This is an embedded message, with a multipart/alternative part.
+ part}
+ part}
+ body}
part}
- attachment{ ID: 5, Content-type: text/plain
+ attachment{ ID: 7, Content-type: text/plain
Attachment: attachment (text/plain)
This is a text attachment.
attachment}
- part{ ID: 6, Content-type: text/plain
+ part{ ID: 8, Content-type: text/plain
And this message is signed.
-Carl
part}
part}
- part{ ID: 7, Content-type: application/pgp-signature
+ part{ ID: 9, Content-type: application/pgp-signature
Non-text part: application/pgp-signature
part}
part}
@@ -135,21 +163,34 @@ cat OU
cat
[PATCH 2/5] test: Fix date in test message in multipart test.
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 returned as "+", so
we change that here was well.
This will be relevant for later patches when we begin parsing rfc822
part headers, where gmime returns a parsed date string.
If we do want to test date parsing, we should do that in a separate
test.
---
test/multipart | 12 ++--
1 files changed, 6 insertions(+), 6 deletions(-)
diff --git a/test/multipart b/test/multipart
index 9d6a9d1..67e04d9 100755
--- a/test/multipart
+++ b/test/multipart
@@ -6,7 +6,7 @@ cat < ${MAIL_DIR}/multipart
From: Carl Worth
To: cworth at cworth.org
Subject: Multipart message
-Date: Tue, 05 Jan 2001 15:43:57 -
+Date: Fri, 05 Jan 2001 15:43:57 +
User-Agent: Notmuch/0.5 (http://notmuchmail.org) Emacs/23.3.1
(i486-pc-linux-gnu)
Message-ID: <87liy5ap00.fsf at yoom.home.cworth.org>
MIME-Version: 1.0
@@ -23,7 +23,7 @@ Content-Disposition: inline
From: Carl Worth
To: cworth at cworth.org
Subject: html message
-Date: Tue, 05 Jan 2001 15:42:57 -
+Date: Fri, 05 Jan 2001 15:42:57 +
User-Agent: Notmuch/0.5 (http://notmuchmail.org) Emacs/23.3.1
(i486-pc-linux-gnu)
Message-ID: <87liy5ap01.fsf at yoom.home.cworth.org>
MIME-Version: 1.0
@@ -61,7 +61,7 @@ cat < ${MAIL_DIR}/base64-part-with-crlf
From: Carl Worth
To: cworth at cworth.org
Subject: Test message with a BASE64 encoded binary containing CRLF pair
-Date: Tue, 05 Jan 2001 15:43:57 -
+Date: Fri, 05 Jan 2001 15:43:57 +
User-Agent: Notmuch/0.5 (http://notmuchmail.org) Emacs/23.3.1
(i486-pc-linux-gnu)
Message-ID:
MIME-Version: 1.0
@@ -100,7 +100,7 @@ Carl Worth (2001-01-05) (attachment
inbox signed unread)
Subject: Multipart message
From: Carl Worth
To: cworth at cworth.org
-Date: Tue, 05 Jan 2001 15:43:57 -
+Date: Fri, 05 Jan 2001 15:43:57 +
header}
body{
part{ ID: 1, Content-type: multipart/signed
@@ -235,7 +235,7 @@ test_expect_success \
test_begin_subtest "--format=json --part=0, full message"
output=$(notmuch show --format=json --part=0 'id:87liy5ap00.fsf at
yoom.home.cworth.org')
test_expect_equal "$output" \
-'{"id": "87liy5ap00.fsf at yoom.home.cworth.org", "match": true, "filename":
"'"${MAIL_DIR}/multipart"'", "timestamp": 978709437, "date_relative":
"2001-01-05", "tags": ["attachment","inbox","signed","unread"], "headers":
{"Subject": "Multipart message", "From": "Carl Worth ",
"To": "cworth at cworth.org", "Cc": "", "Bcc": "", "Date": "Tue, 05 Jan 2001
15:43:57 -"}, "body": [{"id": 1, "content-type": "multipart/signed",
"content": [{"id": 2, "content-type": "multipart/mixed", "content": [{"id": 3,
"content-type": "message/rfc822", "content": [{"id": 4, "content-type":
"text/html"}]}, {"id": 5, "content-type": "text/plain", "filename":
"attachment", "content": "This is a text attachment.\n"}, {"id": 6,
"content-type": "text/plain", "content": "And this message is
signed.\n\n-Carl\n"}]}, {"id": 7, "content-type":
"application/pgp-signature"}]}]}'
+'{"id": "87liy5ap00.fsf at yoom.home.cworth.org", "match": true, "filename":
"'"${MAIL_DIR}/multipart"'", "timestamp": 978709437, "date_relative":
"2001-01-05", "tags": ["attachment","inbox","signed","unread"], "headers":
{"Subject": "Multipart message", "From": "Carl Worth ",
"To": "cworth at cworth.org", "Cc": "", "Bcc": "", "Date": "Fri, 05 Jan 2001
15:43:57 +"}, "body": [{"id": 1, "content-type": "multipart/signed",
"content": [{"id": 2, "content-type": "multipart/mixed", "content": [{"id": 3,
"content-type": "message/rfc822", "content": [{"id": 4, "content-type":
"text/html"}]}, {"id": 5, "content-type": "text/plain", "filename":
"attachment", "content": "This is a text attachment.\n"}, {"id": 6,
"content-type": "text/plain", "content": "And this message is
signed.\n\n-Carl\n"}]}, {"id": 7, "content-type":
"application/pgp-signature"}]}]}'
test_begin_subtest "--format=json --part=1, message body"
output=$(notmuch show --format=json --part=1 'id:87liy5ap00.fsf at
yoom.home.cworth.org')
@@ -385,7 +385,7 @@ To: Carl Worth , cworth at cworth.org
In-Reply-To: <87liy5ap00.fsf at yoom.home.cworth.org>
References: <87liy5ap00.fsf at yoom.home.cworth.org>
-On Tue, 05 Jan 2001 15:43:57 -, Carl Worth wrote:
+On Fri, 05 Jan 2001 15:43:57 +, Carl Worth wrote:
Non-text part: multipart/signed
Non-text part: multipart/mixed
Non-text part: message/rfc822
--
1.7.4.4
[PATCH 1/5] test: some small fixes to multipart test
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 deletions(-) diff --git a/test/multipart b/test/multipart index 0879696..9d6a9d1 100755 --- a/test/multipart +++ b/test/multipart @@ -129,18 +129,9 @@ Non-text part: application/pgp-signature EOF test_expect_equal_file OUTPUT EXPECTED -test_begin_subtest "--format=text --part=0, full message" -notmuch show --format=text --part=0 'id:87liy5ap00.fsf at yoom.home.cworth.org' >OUTPUT +test_begin_subtest "--format=text --part=1, message body" +notmuch show --format=text --part=1 'id:87liy5ap00.fsf at yoom.home.cworth.org' >OUTPUT cat
improving message/rfc822 part handling
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 to that of the outer message, including "headers" and "body" fields. What this doesn't yet address is the raw output of message/rfc822 parts. The raw output of message/rfc822 parts /should/ be the full raw message. However, I have not yet figured out how to do that yet, so the multipart test for raw message/rfc822 parts is not yet fixed. The problem is really gmime's handling of message parts. There doesn't seem to be a gmime function that will return the message part as a GMimeObject. This means that we can't access all the message headers, or the messages sub parts as mime objects. There may be a way to hack around gmime's limitations, but I haven't figured it out yet. If someone else wants to take a crack at it, that would be great. In the mean time, I'm opening a bug report with gmime to request a function to return the rfc822 part as a GMimeObject. jamie.
[PATCH] Added C-up and C-down to cycle through previous searches
Hi Dima. On Sat, 4 Jun 2011 13:07:32 -0700, Dima Kogan wrote: > > On Sun, 29 May 2011 20:04:00 +0400 > > Dmitry Kurochkin wrote: > > > > Hi Dima. > > > > On Sun, 29 May 2011 01:56:28 -0700, notmuch at dima.secretsauce.net > > wrote: > > > From: Dima Kogan > > > > > > --- > > > > > > Hi. > > > > > > I made a few improvements to the emacs UI. This patch allows the > > > user to scroll through the most recent searches with C-up and > > > C-down while in the search box. > > > > > > > This sounds like a very nice improvement to me! I just have one > > concern: Why C-up and C-down? I believe M-p and M-n would be more > > natural for Emacs users (at least for me :)). > > > > Also, I did not read the code and can not comment on it. But notmuch > > coding style is to use tabs for indentation. I guess .dir-locals.el > > should be improved to set coding style variables for all modes, not > > just C. > > > > Regards, > > Dmitry > > Hi. I have a mild preference to C-up/down, but M-n/p is just fine also. > As for the coding style, I've looked through that file > (notmuch-hello.el), and it doesn't seem to have a consistent style as > far as tabs/spaces go. I'm happy to change my patch to conform, but I > don't know what I should be conforming to. Should I be tab-ing all > indents, or just some? > Notmuch uses a mix of 8 char width tabs and spaces. First go tabs, then, if you need indenting with more precision, spaces. Look at the lines your patch removes for an example. Also, .dir-locals.el sets some variables to configure Emacs for Notmuch coding style but only for c-mode. You may set it by hand for lisp. Regards, Dmitry
[PATCH] Added C-up and C-down to cycle through previous searches
Hi, On Sun, 29 May 2011 20:04:00 +0400, Dmitry Kurochkin wrote: > Hi Dima. > > On Sun, 29 May 2011 01:56:28 -0700, notmuch at dima.secretsauce.net wrote: > > From: Dima Kogan > > > > --- > > > > Hi. > > > > I made a few improvements to the emacs UI. This patch allows the user to > > scroll > > through the most recent searches with C-up and C-down while in the search > > box. > > > > This sounds like a very nice improvement to me! I just have one > concern: Why C-up and C-down? I believe M-p and M-n would be more > natural for Emacs users (at least for me :)). +1. M-p/M-n is way simpler to remember for me too. IMO, that should be setq'able at the user level to suit best users preferences. /Xavier
[PATCH] emacs: Tab completion for notmuch-search and notmuch-search-filter
On Sat, 4 Jun 2011 17:55:24 -0400, Austin Clements wrote: > Oh, sorry, I wasn't suggesting setq'ing a global. I agree that that's > really ugly. Rather, something like > > (defun notmuch-query-completions (string) > ... as you have it now ...) > > (defun notmuch-read-query (prompt) > (let ((notmuch-completions (append (list "folder:" ...))) > (keymap ...) > (minibuffer-completion-table ...)) > (read-from-minibuffer ...))) > > Unfortunately, you still need the global defvar to avoid compilation > warnings, but this at least avoids the side-effects, and is probably > how programmed completion was intended to be used. Both alternatives seem about equally ugly to me, since the one using dynamic scoping still uses side-effects, because it still passes the completion information around without using it as an argument to notmuch-query-completions. At least defvar-ing a global variable and then never actually using it, seems somewhat unclean as well. > Alternatively, here's a completely different way to structure this > that avoids globals and dynamic scoping entirely. This is how some of > the standard completing read functions appear to work: Ah right, I forgot that using macros from cl is fine even in library code. -- next part -- A non-text attachment was scrubbed... Name: 0001-emacs-Tab-completion-for-notmuch-search-and-notmuch-.patch Type: text/x-diff Size: 3290 bytes Desc: not available URL: <http://notmuchmail.org/pipermail/notmuch/attachments/20110605/e41a2048/attachment-0001.patch> -- 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/20110605/e41a2048/attachment-0001.pgp>
Re: [PATCH] Added C-up and C-down to cycle through previous searches
Hi, On Sun, 29 May 2011 20:04:00 +0400, Dmitry Kurochkin dmitry.kuroch...@gmail.com wrote: Hi Dima. On Sun, 29 May 2011 01:56:28 -0700, notm...@dima.secretsauce.net wrote: From: Dima Kogan d...@secretsauce.net --- Hi. I made a few improvements to the emacs UI. This patch allows the user to scroll through the most recent searches with C-up and C-down while in the search box. This sounds like a very nice improvement to me! I just have one concern: Why C-up and C-down? I believe M-p and M-n would be more natural for Emacs users (at least for me :)). +1. M-p/M-n is way simpler to remember for me too. IMO, that should be setq'able at the user level to suit best users preferences. /Xavier ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
Re: [PATCH] fix sum moar typos
Hi Pieter, On Sat, 4 Jun 2011 17:54:12 +0200, Pieter Praet pie...@praet.org wrote: Because they cause global warming. Signed-off-by: Pieter Praet pie...@praet.org --- TL;DR: Various typo fixes. Applies to jrollins/release-candidate/0.6 (2baf08f5) Due to the impending 0.6 release, I've gone off on an ephemeral typo hunt, and have brought back some trophies. As it's such an utterly amusing passtime, I've been pretty fat-fingered about it, and wouldn't be surprised if I've missed some, or even made some new ones. Nonetheless: Lets maek 0.6 purrfec! Yaeh ! /Xavier P.S: good job ! ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
[PATCH 4/5] Improve handling of message/rfc822 parts by adding a new header_message_part function to the formating structure.
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 +
notmuch-reply.c | 31 ++-
notmuch-show.c | 88 ++---
show-message.c | 12 +++
4 files changed, 119 insertions(+), 13 deletions(-)
diff --git a/notmuch-client.h b/notmuch-client.h
index 63be337..b50cb38 100644
--- a/notmuch-client.h
+++ b/notmuch-client.h
@@ -63,6 +63,7 @@ typedef struct notmuch_show_format {
const char *header_start;
void (*header) (const void *ctx,
notmuch_message_t *message);
+void (*header_message_part) (GMimeMessage *message);
const char *header_end;
const char *body_start;
void (*part_start) (GMimeObject *part,
diff --git a/notmuch-reply.c b/notmuch-reply.c
index 514bbc6..a19eb19 100644
--- a/notmuch-reply.c
+++ b/notmuch-reply.c
@@ -25,12 +25,15 @@
#include gmime-filter-headers.h
static void
+reply_headers_message_part (GMimeMessage *message);
+
+static void
reply_part_content (GMimeObject *part);
static const notmuch_show_format_t format_reply = {
,
, NULL,
- , NULL, ,
+ , NULL, reply_headers_message_part, \n,
,
NULL,
NULL,
@@ -63,6 +66,28 @@ show_reply_headers (GMimeMessage *message)
}
static void
+reply_headers_message_part (GMimeMessage *message)
+{
+InternetAddressList *recipients;
+const char *recipients_string;
+
+printf ( From: %s\n, g_mime_message_get_sender (message));
+recipients = g_mime_message_get_recipients (message,
GMIME_RECIPIENT_TYPE_TO);
+recipients_string = internet_address_list_to_string (recipients, 0);
+if (recipients_string)
+ printf ( To: %s\n,
+ recipients_string);
+recipients = g_mime_message_get_recipients (message,
GMIME_RECIPIENT_TYPE_CC);
+recipients_string = internet_address_list_to_string (recipients, 0);
+if (recipients_string)
+ printf ( Cc: %s\n,
+ recipients_string);
+printf ( Subject: %s\n, g_mime_message_get_subject (message));
+printf ( Date: %s\n, g_mime_message_get_date_as_string (message));
+}
+
+
+static void
reply_part_content (GMimeObject *part)
{
GMimeContentType *content_type = g_mime_object_get_content_type
(GMIME_OBJECT (part));
@@ -95,6 +120,10 @@ reply_part_content (GMimeObject *part)
if (stream_stdout)
g_object_unref(stream_stdout);
}
+else if (g_mime_content_type_is_type (content_type, message, rfc822))
+{
+ /* Output nothing, since rfc822 subparts will be handled individually.
*/
+}
else
{
if (disposition
diff --git a/notmuch-show.c b/notmuch-show.c
index 0e9d00d..6e2e560 100644
--- a/notmuch-show.c
+++ b/notmuch-show.c
@@ -29,6 +29,9 @@ format_headers_text (const void *ctx,
notmuch_message_t *message);
static void
+format_headers_message_part_text (GMimeMessage *message);
+
+static void
format_part_start_text (GMimeObject *part,
int *part_count);
@@ -41,7 +44,7 @@ format_part_end_text (GMimeObject *part);
static const notmuch_show_format_t format_text = {
,
\fmessage{ , format_message_text,
- \fheader{\n, format_headers_text, \fheader}\n,
+ \fheader{\n, format_headers_text,
format_headers_message_part_text, \fheader}\n,
\fbody{\n,
format_part_start_text,
NULL,
@@ -63,6 +66,9 @@ format_headers_json (const void *ctx,
notmuch_message_t *message);
static void
+format_headers_message_part_json (GMimeMessage *message);
+
+static void
format_part_start_json (unused (GMimeObject *part),
int *part_count);
@@ -81,7 +87,7 @@ format_part_end_json (GMimeObject *part);
static const notmuch_show_format_t format_json = {
[,
{, format_message_json,
- , \headers\: {, format_headers_json, },
+ \headers\: {, format_headers_json,
format_headers_message_part_json, },
, \body\: [,
format_part_start_json,
format_part_encstatus_json,
@@ -102,7 +108,7 @@ format_message_mbox (const void *ctx,
static const notmuch_show_format_t format_mbox = {
,
, format_message_mbox,
-, NULL, ,
+, NULL, NULL, ,
,
NULL,
NULL,
@@ -121,7 +127,7 @@ format_part_content_raw (GMimeObject *part);
static const notmuch_show_format_t format_raw = {
,
, NULL,
- , NULL, ,
+ , NULL, format_headers_message_part_text, \n,
,
NULL,
NULL,
@@ -216,7 +222,7 @@ format_message_json (const void *ctx, notmuch_message_t
*message,
[PATCH 5/5] emacs: Improve support for message/rfc822 parts.
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 files changed, 13 insertions(+), 8 deletions(-) diff --git a/emacs/notmuch-show.el b/emacs/notmuch-show.el index 7d848e3..0f1fe69 100644 --- a/emacs/notmuch-show.el +++ b/emacs/notmuch-show.el @@ -519,21 +519,26 @@ current buffer, if possible. t) (defun notmuch-show-insert-part-message/rfc822 (msg part content-type nth depth declared-type) - (let* ((message-part (plist-get part :content)) -(inner-parts (plist-get message-part :content))) -(notmuch-show-insert-part-header nth declared-type content-type nil) + (notmuch-show-insert-part-header nth declared-type content-type nil) + (let* ((message (car (plist-get part :content))) +(headers (plist-get message :headers)) +(body (car (plist-get message :body))) +(start (point))) + ;; Override `notmuch-message-headers' to force `From' to be ;; displayed. (let ((notmuch-message-headers '(From Subject To Cc Date))) - (notmuch-show-insert-headers (plist-get part :headers))) + (notmuch-show-insert-headers (plist-get message :headers))) + ;; Blank line after headers to be compatible with the normal ;; message display. (insert \n) -;; Show all of the parts. -(mapc (lambda (inner-part) - (notmuch-show-insert-bodypart msg inner-part depth)) - inner-parts)) +;; Show the body +(notmuch-show-insert-bodypart msg body depth) + +(when notmuch-show-indent-multipart + (indent-rigidly start (point) 1))) t) (defun notmuch-show-insert-part-text/plain (msg part content-type nth depth declared-type) -- 1.7.4.4 ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
[PATCH 2/5] test: Fix date in test message in multipart test.
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 returned as +, so
we change that here was well.
This will be relevant for later patches when we begin parsing rfc822
part headers, where gmime returns a parsed date string.
If we do want to test date parsing, we should do that in a separate
test.
---
test/multipart | 12 ++--
1 files changed, 6 insertions(+), 6 deletions(-)
diff --git a/test/multipart b/test/multipart
index 9d6a9d1..67e04d9 100755
--- a/test/multipart
+++ b/test/multipart
@@ -6,7 +6,7 @@ cat EOF ${MAIL_DIR}/multipart
From: Carl Worth cwo...@cworth.org
To: cwo...@cworth.org
Subject: Multipart message
-Date: Tue, 05 Jan 2001 15:43:57 -
+Date: Fri, 05 Jan 2001 15:43:57 +
User-Agent: Notmuch/0.5 (http://notmuchmail.org) Emacs/23.3.1
(i486-pc-linux-gnu)
Message-ID: 87liy5ap00@yoom.home.cworth.org
MIME-Version: 1.0
@@ -23,7 +23,7 @@ Content-Disposition: inline
From: Carl Worth cwo...@cworth.org
To: cwo...@cworth.org
Subject: html message
-Date: Tue, 05 Jan 2001 15:42:57 -
+Date: Fri, 05 Jan 2001 15:42:57 +
User-Agent: Notmuch/0.5 (http://notmuchmail.org) Emacs/23.3.1
(i486-pc-linux-gnu)
Message-ID: 87liy5ap01@yoom.home.cworth.org
MIME-Version: 1.0
@@ -61,7 +61,7 @@ cat EOF ${MAIL_DIR}/base64-part-with-crlf
From: Carl Worth cwo...@cworth.org
To: cwo...@cworth.org
Subject: Test message with a BASE64 encoded binary containing CRLF pair
-Date: Tue, 05 Jan 2001 15:43:57 -
+Date: Fri, 05 Jan 2001 15:43:57 +
User-Agent: Notmuch/0.5 (http://notmuchmail.org) Emacs/23.3.1
(i486-pc-linux-gnu)
Message-ID: base64-part-with-crlf
MIME-Version: 1.0
@@ -100,7 +100,7 @@ Carl Worth cwo...@cworth.org (2001-01-05) (attachment
inbox signed unread)
Subject: Multipart message
From: Carl Worth cwo...@cworth.org
To: cwo...@cworth.org
-Date: Tue, 05 Jan 2001 15:43:57 -
+Date: Fri, 05 Jan 2001 15:43:57 +
header}
body{
part{ ID: 1, Content-type: multipart/signed
@@ -235,7 +235,7 @@ test_expect_success \
test_begin_subtest --format=json --part=0, full message
output=$(notmuch show --format=json --part=0
'id:87liy5ap00@yoom.home.cworth.org')
test_expect_equal $output \
-'{id: 87liy5ap00@yoom.home.cworth.org, match: true, filename:
'${MAIL_DIR}/multipart', timestamp: 978709437, date_relative:
2001-01-05, tags: [attachment,inbox,signed,unread], headers:
{Subject: Multipart message, From: Carl Worth cwo...@cworth.org,
To: cwo...@cworth.org, Cc: , Bcc: , Date: Tue, 05 Jan 2001
15:43:57 -}, body: [{id: 1, content-type: multipart/signed,
content: [{id: 2, content-type: multipart/mixed, content: [{id: 3,
content-type: message/rfc822, content: [{id: 4, content-type:
text/html}]}, {id: 5, content-type: text/plain, filename:
attachment, content: This is a text attachment.\n}, {id: 6,
content-type: text/plain, content: And this message is
signed.\n\n-Carl\n}]}, {id: 7, content-type:
application/pgp-signature}]}]}'
+'{id: 87liy5ap00@yoom.home.cworth.org, match: true, filename:
'${MAIL_DIR}/multipart', timestamp: 978709437, date_relative:
2001-01-05, tags: [attachment,inbox,signed,unread], headers:
{Subject: Multipart message, From: Carl Worth cwo...@cworth.org,
To: cwo...@cworth.org, Cc: , Bcc: , Date: Fri, 05 Jan 2001
15:43:57 +}, body: [{id: 1, content-type: multipart/signed,
content: [{id: 2, content-type: multipart/mixed, content: [{id: 3,
content-type: message/rfc822, content: [{id: 4, content-type:
text/html}]}, {id: 5, content-type: text/plain, filename:
attachment, content: This is a text attachment.\n}, {id: 6,
content-type: text/plain, content: And this message is
signed.\n\n-Carl\n}]}, {id: 7, content-type:
application/pgp-signature}]}]}'
test_begin_subtest --format=json --part=1, message body
output=$(notmuch show --format=json --part=1
'id:87liy5ap00@yoom.home.cworth.org')
@@ -385,7 +385,7 @@ To: Carl Worth cwo...@cworth.org, cwo...@cworth.org
In-Reply-To: 87liy5ap00@yoom.home.cworth.org
References: 87liy5ap00@yoom.home.cworth.org
-On Tue, 05 Jan 2001 15:43:57 -, Carl Worth cwo...@cworth.org wrote:
+On Fri, 05 Jan 2001 15:43:57 +, Carl Worth cwo...@cworth.org wrote:
Non-text part: multipart/signed
Non-text part: multipart/mixed
Non-text part: message/rfc822
--
1.7.4.4
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch
improving message/rfc822 part handling
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 to that of the outer message, including headers and body fields. What this doesn't yet address is the raw output of message/rfc822 parts. The raw output of message/rfc822 parts /should/ be the full raw message. However, I have not yet figured out how to do that yet, so the multipart test for raw message/rfc822 parts is not yet fixed. The problem is really gmime's handling of message parts. There doesn't seem to be a gmime function that will return the message part as a GMimeObject. This means that we can't access all the message headers, or the messages sub parts as mime objects. There may be a way to hack around gmime's limitations, but I haven't figured it out yet. If someone else wants to take a crack at it, that would be great. In the mean time, I'm opening a bug report with gmime to request a function to return the rfc822 part as a GMimeObject. jamie. ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
[PATCH 1/5] test: some small fixes to multipart test
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 deletions(-)
diff --git a/test/multipart b/test/multipart
index 0879696..9d6a9d1 100755
--- a/test/multipart
+++ b/test/multipart
@@ -129,18 +129,9 @@ Non-text part: application/pgp-signature
EOF
test_expect_equal_file OUTPUT EXPECTED
-test_begin_subtest --format=text --part=0, full message
-notmuch show --format=text --part=0 'id:87liy5ap00@yoom.home.cworth.org'
OUTPUT
+test_begin_subtest --format=text --part=1, message body
+notmuch show --format=text --part=1 'id:87liy5ap00@yoom.home.cworth.org'
OUTPUT
cat EOF EXPECTED
- message{ id:87liy5ap00@yoom.home.cworth.org depth:0 match:1
filename:${MAIL_DIR}/multipart
- header{
-Carl Worth cwo...@cworth.org (2001-01-05) (attachment inbox signed unread)
-Subject: Multipart message
-From: Carl Worth cwo...@cworth.org
-To: cwo...@cworth.org
-Date: Tue, 05 Jan 2001 15:43:57 -
- header}
- body{
part{ ID: 1, Content-type: multipart/signed
part{ ID: 2, Content-type: multipart/mixed
part{ ID: 3, Content-type: message/rfc822
@@ -162,8 +153,6 @@ And this message is signed.
Non-text part: application/pgp-signature
part}
part}
- body}
- message}
EOF
test_expect_equal_file OUTPUT EXPECTED
@@ -257,13 +246,11 @@ test_begin_subtest --format=json --part=2,
multipart/mixed
output=$(notmuch show --format=json --part=2
'id:87liy5ap00@yoom.home.cworth.org')
test_expect_equal $output \
'{id: 2, content-type: multipart/mixed, content: [{id: 3,
content-type: message/rfc822, content: [{id: 4, content-type:
text/html}]}, {id: 5, content-type: text/plain, filename:
attachment, content: This is a text attachment.\n}, {id: 6,
content-type: text/plain, content: And this message is
signed.\n\n-Carl\n}]}'
-test_expect_equal_file OUTPUT EXPECTED
test_begin_subtest --format=json --part=3, rfc822 multipart
output=$(notmuch show --format=json --part=3
'id:87liy5ap00@yoom.home.cworth.org')
test_expect_equal $output \
'{id: 3, content-type: message/rfc822, content: [{id: 4,
content-type: text/html}]}'
-test_expect_equal_file OUTPUT EXPECTED
test_begin_subtest --format=json --part=4, html part
output=$(notmuch show --format=json --part=4
'id:87liy5ap00@yoom.home.cworth.org')
--
1.7.4.4
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch
[PATCH 3/5] test: overhaul multipart test to test for improved message/rfc822 handling
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 format and content of message/rfc822 parts shall be as similar as
possible to that of full messages. In particular, for formatted
outputs, the content of rfc822 part output should include headers
and body fields).
The body field shall include the body of the message.
The headers field shall include the following headers, since these
are the ones available from the GMimeMessage:
From
To
Cc
Subject
Date
However, for the case of --format=raw the raw rfc822 should be output,
including all headers.
A subset of relevant headers shall be output in reply.
The test embedded rfc822 message is also modified to be itself
multipart, so we can more fully test how all sub parts of the message
part are output.
---
test/multipart | 368 +++-
1 files changed, 283 insertions(+), 85 deletions(-)
diff --git a/test/multipart b/test/multipart
index 67e04d9..95577dc 100755
--- a/test/multipart
+++ b/test/multipart
@@ -2,6 +2,29 @@
test_description=output of multipart message
. ./test-lib.sh
+cat EOF embedded_message
+From: Carl Worth cwo...@cworth.org
+To: cwo...@cworth.org
+Subject: html message
+Date: Fri, 05 Jan 2001 15:42:57 +
+User-Agent: Notmuch/0.5 (http://notmuchmail.org) Emacs/23.3.1
(i486-pc-linux-gnu)
+Message-ID: 87liy5ap01@yoom.home.cworth.org
+MIME-Version: 1.0
+Content-Type: multipart/alternative; boundary===-=-==
+
+--==-=-==
+Content-Type: text/html
+
+pThis is an embedded message, with a multipart/alternative part./p
+
+--==-=-==
+Content-Type: text/plain
+
+This is an embedded message, with a multipart/alternative part.
+
+--==-=-==--
+EOF
+
cat EOF ${MAIL_DIR}/multipart
From: Carl Worth cwo...@cworth.org
To: cwo...@cworth.org
@@ -20,17 +43,9 @@ Content-Type: multipart/mixed; boundary==-=-=
Content-Type: message/rfc822
Content-Disposition: inline
-From: Carl Worth cwo...@cworth.org
-To: cwo...@cworth.org
-Subject: html message
-Date: Fri, 05 Jan 2001 15:42:57 +
-User-Agent: Notmuch/0.5 (http://notmuchmail.org) Emacs/23.3.1
(i486-pc-linux-gnu)
-Message-ID: 87liy5ap01@yoom.home.cworth.org
-MIME-Version: 1.0
-Content-Type: text/html
-
-pThis is an embedded message, with a single html part./p
-
+EOF
+cat embedded_message ${MAIL_DIR}/multipart
+cat EOF ${MAIL_DIR}/multipart
--=-=-=
Content-Disposition: attachment; filename=attachment
@@ -106,21 +121,34 @@ Date: Fri, 05 Jan 2001 15:43:57 +
part{ ID: 1, Content-type: multipart/signed
part{ ID: 2, Content-type: multipart/mixed
part{ ID: 3, Content-type: message/rfc822
- part{ ID: 4, Content-type: text/html
+ header{
+From: Carl Worth cwo...@cworth.org
+To: cwo...@cworth.org
+Subject: html message
+Date: Fri, 05 Jan 2001 15:42:57 +
+ header}
+ body{
+ part{ ID: 4, Content-type: multipart/alternative
+ part{ ID: 5, Content-type: text/html
Non-text part: text/html
part}
+ part{ ID: 6, Content-type: text/plain
+This is an embedded message, with a multipart/alternative part.
+ part}
+ part}
+ body}
part}
- attachment{ ID: 5, Content-type: text/plain
+ attachment{ ID: 7, Content-type: text/plain
Attachment: attachment (text/plain)
This is a text attachment.
attachment}
- part{ ID: 6, Content-type: text/plain
+ part{ ID: 8, Content-type: text/plain
And this message is signed.
-Carl
part}
part}
- part{ ID: 7, Content-type: application/pgp-signature
+ part{ ID: 9, Content-type: application/pgp-signature
Non-text part: application/pgp-signature
part}
part}
@@ -135,21 +163,34 @@ cat EOF EXPECTED
part{ ID: 1, Content-type: multipart/signed
part{ ID: 2, Content-type: multipart/mixed
part{ ID: 3, Content-type: message/rfc822
- part{ ID: 4, Content-type: text/html
+ header{
+From: Carl Worth cwo...@cworth.org
+To: cwo...@cworth.org
+Subject: html message
+Date: Fri, 05 Jan 2001 15:42:57 +
+ header}
+ body{
+ part{ ID: 4, Content-type: multipart/alternative
+ part{ ID: 5, Content-type: text/html
Non-text part: text/html
part}
+ part{ ID: 6, Content-type: text/plain
+This is an embedded message, with a multipart/alternative part.
+ part}
part}
- attachment{ ID: 5, Content-type: text/plain
+ body}
+ part}
+ attachment{ ID: 7, Content-type: text/plain
Attachment: attachment (text/plain)
This is a text attachment.
attachment}
- part{ ID: 6, Content-type: text/plain
+ part{ ID: 8, Content-type: text/plain
And this message is signed.
-Carl
part}
part}
- part{ ID: 7, Content-type: application/pgp-signature
+ part{ ID: 9, Content-type: application/pgp-signature
Non-text part: application/pgp-signature
part}
part}
@@ -161,15 +202,28 @@ notmuch show --format=text --part=2
'id:87liy5ap00@yoom.home.cworth.org' OU
cat EOF
Re: improving message/rfc822 part handling
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 ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
Re: release-candidate/0.6 redux
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 notmuch-crypto-process-mime config variable documentation. Hey, Carl. This is actually a five-patch series that starts at: emacs: add notmuch-show-refresh-view function id:1306627784-3401-1-git-send-email-jroll...@finestructure.net You should also look at the following two patch series to fix the message/rfc822 part handling: Do not attept to output part raw if part is not GMimePart. id:1307120466-4980-1-git-send-email-jroll...@finestructure.net improving message/rfc822 part handling id:1307320169-29905-1-git-send-email-jroll...@finestructure.net jamie. pgpw9OBIslcuw.pgp Description: PGP signature ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
Re: improving message/rfc822 part handling
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 http://notmuchmail.org/mailman/listinfo/notmuch
