Patchworkβ emacs: On getting support for inline images

login
register
about
Submitter Carl Worth
Date 2010-02-10 20:54:52
Message ID <877hqk4xr7.fsf@yoom.home.cworth.org>
Download mbox | patch
Permalink /patch/353/
State New
Headers show

Comments

Carl Worth - 2010-02-10 20:54:52
On Wed, 10 Feb 2010 12:20:00 -0800, Carl Worth <cworth@cworth.org> wrote:
> Here are some ideas for possible (and independent) fixes:
> 
> 1. With the current setup, we know we are using a temporary buffer that
>    the user won't see, so notmuch could temporarily set
>    mm-inline-media-tests to nil forcing everything to use external
>    viewers when the user presses 'v'.

Below is a patch to implement this piece.

It seems to do the trick so that I can now actually view image
attachments with 'v' (hurrah!). So I think I'll push this now.

-Carl

PS. I know that attaching the output of "git format-patch" to a message
like this isn't the "git way". (That is, you won't get the right result
by simply piping this message to "git am".) But I really wish it
were. It seems I often write code in response to an email message and I
often want to reply to that *message* and incidentally provide a
patch. The git way, with the commit message in the subject and the first
part of the body seems backwards to me, (as far as the conversation is
concerned).

PPS. If I did want to construct this message in the "git way", but
without using git-send-mail, I know how to construct the subject line
and how to put explanatory text like this below the separator. But what
am I supposed to do with the commit identifier that appears in an mbox
"From" line in the format-patch output? I assume this is required for
"git am -3" to work, but where can I put it in an email message?
Michal Sojka - 2010-02-10 23:36:42
On Wed, 10 Feb 2010 12:54:52 -0800, Carl Worth <cworth@cworth.org> wrote:
> PS. I know that attaching the output of "git format-patch" to a message
> like this isn't the "git way". (That is, you won't get the right result
> by simply piping this message to "git am".) But I really wish it
> were. It seems I often write code in response to an email message and I
> often want to reply to that *message* and incidentally provide a
> patch. The git way, with the commit message in the subject and the first
> part of the body seems backwards to me, (as far as the conversation is
> concerned).

Hi Carl,

this is what scissors line was designed for. At least according to
git-mailinfo(1). "git am -c" should take it into account as well.

I wanted to test this with my previous patch I sent this way, but I get
fatal: corrupt patch at line 27. So I do not know whether it really works.

> PPS. If I did want to construct this message in the "git way", but
> without using git-send-mail, I know how to construct the subject line
> and how to put explanatory text like this below the separator. But what
> am I supposed to do with the commit identifier that appears in an mbox
> "From" line in the format-patch output? I assume this is required for
> "git am -3" to work, but where can I put it in an email message?

I'm not sure whether From line is used for 3 way merge. It seems that
mails produced by git send-email do not contain it. I think that the
index lines just after diff --git could be sufficient for 3 way merge.
Is it correct?

Michal
David Edmondson - 2010-02-11 08:00:16
> PS. I know that attaching the output of "git format-patch" to a message
> like this isn't the "git way". (That is, you won't get the right result
> by simply piping this message to "git am".) But I really wish it
> were. It seems I often write code in response to an email message and I
> often want to reply to that *message* and incidentally provide a
> patch. The git way, with the commit message in the subject and the first
> part of the body seems backwards to me, (as far as the conversation is
> concerned).

How about attaching a message/rfc822 part which contains the patch?

Patch

From 2174adf374370135061bd80db21cbd43bbac95ab Mon Sep 17 00:00:00 2001
From: Carl Worth <cworth@cworth.org>
Date: Wed, 10 Feb 2010 12:40:47 -0800
Subject: [PATCH] notmuch.el: Handle attached images via an external viewer.

We temporarily override the mm-inline-media-tests variable so that the
only parts inserted into the temporary buffer (and lost) are those
parts that the user has already seen in the notmuch-show buffer.

Anything else, (such as images), will now be left to be handled via
mailcap, just like other attachment types.
---
 notmuch.el |   17 ++++++++++++++++-
 1 files changed, 16 insertions(+), 1 deletions(-)

diff --git a/notmuch.el b/notmuch.el
index b909567..040997e 100644
--- a/notmuch.el
+++ b/notmuch.el
@@ -327,7 +327,22 @@  buffer."
   "Use external viewers to view all attachments from the current message."
   (interactive)
   (with-current-notmuch-show-message
-   (mm-display-parts (mm-dissect-buffer))))
+   ; We ovverride the mm-inline-media-tests to indicate which message
+   ; parts are already sufficiently handled by the original
+   ; presentation of the message in notmuch-show mode. These parts
+   ; will be inserted directly into the temporary buffer of
+   ; with-current-notmuch-show-message and silently discarded.
+   ;
+   ; Any MIME part not explicitly mentioned here will be handled by an
+   ; external viewer as configured in the various mailcap files.
+   (let ((mm-inline-media-tests '(
+				  ("text/.*" ignore identity)
+				  ("application/pgp-signature" ignore identity)
+				  ("multipart/alternative" ignore identity)
+				  ("multipart/mixed" ignore identity)
+				  ("multipart/related" ignore identity)
+				 )))
+     (mm-display-parts (mm-dissect-buffer)))))
 
 (defun notmuch-foreach-mime-part (function mm-handle)
   (cond ((stringp (car mm-handle))
-- 
1.6.5.7