[notmuch] emacs: On getting support for inline images

[David Edmondson]

> 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?

[notmuch] emacs: On getting support for inline images

[Michal Sojka]

On Wed, 10 Feb 2010 12:54:52 -0800, Carl Worth  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

Re: [notmuch] emacs: On getting support for inline images

[David Edmondson]

> 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?
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch

[notmuch] emacs: On getting support for inline images

[micah anderson]

On Wed, 10 Feb 2010 12:20:00 -0800, Carl Worth  wrote:
> I investigated a bit and discovered that the images are being rendered
> within emacs and inside of a temporary buffer that is being used by the
> function invoked by 'v'. Before this function returns, the temporary
> buffer including the nicely inline-rendered image is being killed. (And
> I suspect the exact same thing is happening with encrypted messages
> where hitting 'v' gets emacs to prompt for the passphrase, but then
> nothing is displayed to the user.)
> 
> I was able to get images working by customizing the
> mm-inline-media-tests variable. I removed the image/png clause from the
> value, and now when I hit 'v' I get a nice, external image viewer as
> configured in /etc/mailcap, etc.
> 
> 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'.

This would leave encrypted messages in a weird spot. What external
viewer would you want to be launched when you press 'v' on an encrypted
message? I'd like it to be emacs myself, and even better I want it to be
in notmuch/mml-mode so I can reply to it and get quoting. Although this
option seems like the easiest solution, it avoids the problem, and
unfortunately not very well. Emacs can display images and PDFs fine too,
it just can't do openoffice documents, yet ;)

> 2. The original presentation of Mime parts could examine
>mm-inline-media-tests and directly render anything possible within
>the original presentation of the message. This would allow images to
>be viewed directly without requiring the user to press 'v'. And the
>user could configure this existing variable to control what content
>is displayed inline.

This seems like the right way to handle things in the emacs mode.

> 3. We could move away from these various mm- functions for displaying
>MIME parts and simply add functionality to the notmuch command line
>for extracting individual MIME parts from messages, (which is
>something that a non-emacs client will likely want anyway). Then we
>can use the lower-level functions to display things directly. (For
>example, displaying an image looks as simple as calling the
>create-image and put-image functions).

I would think that the mm functions are probably pretty battle-tested
and have been in a lot of very careful honing over the years. They
probably do the right thing, and do it well because a lot of work has
gone into getting them right. I'm sure there is a big here and there,
but still it seems like it would be a shame not to use something that
has a pretty full feature-set. 

On the other-hand, I see your point about non-emacs clients, and the
command-line having the ability to parse our MIME parts. Perhaps there
is room for both to play?

micah
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 835 bytes
Desc: not available
URL: 

Re: [notmuch] emacs: On getting support for inline images

[micah anderson]

On Wed, 10 Feb 2010 12:20:00 -0800, Carl Worth  wrote:
> I investigated a bit and discovered that the images are being rendered
> within emacs and inside of a temporary buffer that is being used by the
> function invoked by 'v'. Before this function returns, the temporary
> buffer including the nicely inline-rendered image is being killed. (And
> I suspect the exact same thing is happening with encrypted messages
> where hitting 'v' gets emacs to prompt for the passphrase, but then
> nothing is displayed to the user.)
> 
> I was able to get images working by customizing the
> mm-inline-media-tests variable. I removed the image/png clause from the
> value, and now when I hit 'v' I get a nice, external image viewer as
> configured in /etc/mailcap, etc.
> 
> 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'.

This would leave encrypted messages in a weird spot. What external
viewer would you want to be launched when you press 'v' on an encrypted
message? I'd like it to be emacs myself, and even better I want it to be
in notmuch/mml-mode so I can reply to it and get quoting. Although this
option seems like the easiest solution, it avoids the problem, and
unfortunately not very well. Emacs can display images and PDFs fine too,
it just can't do openoffice documents, yet ;)

> 2. The original presentation of Mime parts could examine
>mm-inline-media-tests and directly render anything possible within
>the original presentation of the message. This would allow images to
>be viewed directly without requiring the user to press 'v'. And the
>user could configure this existing variable to control what content
>is displayed inline.

This seems like the right way to handle things in the emacs mode.

> 3. We could move away from these various mm- functions for displaying
>MIME parts and simply add functionality to the notmuch command line
>for extracting individual MIME parts from messages, (which is
>something that a non-emacs client will likely want anyway). Then we
>can use the lower-level functions to display things directly. (For
>example, displaying an image looks as simple as calling the
>create-image and put-image functions).

I would think that the mm functions are probably pretty battle-tested
and have been in a lot of very careful honing over the years. They
probably do the right thing, and do it well because a lot of work has
gone into getting them right. I'm sure there is a big here and there,
but still it seems like it would be a shame not to use something that
has a pretty full feature-set. 

On the other-hand, I see your point about non-emacs clients, and the
command-line having the ability to parse our MIME parts. Perhaps there
is room for both to play?

micah


pgphpQ8bRiNQ6.pgp
Description: PGP signature
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch

[notmuch] emacs: On getting support for inline images

[Jesse Rosenthal]

On Wed, 10 Feb 2010 12:20:00 -0800, Carl Worth  wrote:
> Here are some ideas for possible (and independent) fixes:
> 
> 3. We could move away from these various mm- functions for displaying
>MIME parts and simply add functionality to the notmuch command line
>for extracting individual MIME parts from messages, (which is
>something that a non-emacs client will likely want anyway). Then we
>can use the lower-level functions to display things directly. (For
>example, displaying an image looks as simple as calling the
>create-image and put-image functions).

I really think that this (#3) is the way to go, going forward. First, it
frees us up from the various slownesses and eccentricities of the mm-
modes. Second, and more importantly, it makes it a *lot* easier for
other clients to play, for the remote use of the existing emacs client,
and for scripted command-line usage (e.g. put all the attached vcards in
your maildir into a directory).

I've been playing around with this a bit, for my own purposes,
already. Unfortunately, my autodidact's c code is probably all sorts of
wrong, and I wouldn't want to subject anyone to it. But it does seem
like the way to go, and I'd be very happy to help out with any testing,
if anyone goes forwad with this.

Best,
Jesse

Re: [notmuch] emacs: On getting support for inline images

[Michal Sojka]

On Wed, 10 Feb 2010 12:54:52 -0800, Carl Worth  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
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch

Re: [notmuch] emacs: On getting support for inline images

[Jesse Rosenthal]

On Wed, 10 Feb 2010 12:20:00 -0800, Carl Worth  wrote:
> Here are some ideas for possible (and independent) fixes:
> 
> 3. We could move away from these various mm- functions for displaying
>MIME parts and simply add functionality to the notmuch command line
>for extracting individual MIME parts from messages, (which is
>something that a non-emacs client will likely want anyway). Then we
>can use the lower-level functions to display things directly. (For
>example, displaying an image looks as simple as calling the
>create-image and put-image functions).

I really think that this (#3) is the way to go, going forward. First, it
frees us up from the various slownesses and eccentricities of the mm-
modes. Second, and more importantly, it makes it a *lot* easier for
other clients to play, for the remote use of the existing emacs client,
and for scripted command-line usage (e.g. put all the attached vcards in
your maildir into a directory).

I've been playing around with this a bit, for my own purposes,
already. Unfortunately, my autodidact's c code is probably all sorts of
wrong, and I wouldn't want to subject anyone to it. But it does seem
like the way to go, and I'd be very happy to help out with any testing,
if anyone goes forwad with this.

Best,
Jesse
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch

[notmuch] emacs: On getting support for inline images

[Alexander Botero-Lowry]

On Wed, 10 Feb 2010 12:20:00 -0800, Carl Worth  wrote:
> For a while I've seen that I can very conveniently deal with attachments
> such as PDF files or even OpenOffice (or PowerPoint) presentations with
> the notmuch/emacs client. I simply hit 'v' and an external viewer comes
> up with the attached file. That's all very nice.
> 
Yeah, though it would b enice if we had more fine-grained control over
it, like allowing you to save a file regardless of mm-* thinks it should
get to display it or not.

> 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'.
> 
I think this is a crappy, but perfectly fine temporary fix. 

> 2. The original presentation of Mime parts could examine
>mm-inline-media-tests and directly render anything possible within
>the original presentation of the message. This would allow images to
>be viewed directly without requiring the user to press 'v'. And the
>user could configure this existing variable to control what content
>is displayed inline.
>
Yes, I think some kind of mapping of interesting parts in the message to
the mm-dissect-buffer parts and extending the text/html only inliner to
also inline those interesting parts is the right thing (tm).

Which points out a huge issue in my current inlining code, the parts
aren't actually mapped, we're basically counting on the coincidence that
the parts are in the correct place when we do the inlining, and that
seems to basically work. That being said, it's the cause of some
messages occasionally giving you a save dialog, or failing to be parsed
correctly.

> 3. We could move away from these various mm- functions for displaying
>MIME parts and simply add functionality to the notmuch command line
>for extracting individual MIME parts from messages, (which is
>something that a non-emacs client will likely want anyway). Then we
>can use the lower-level functions to display things directly. (For
>example, displaying an image looks as simple as calling the
>create-image and put-image functions).
>
Just talking about this on IRC. I think this is the wrong approach but
with some right bits. notmuch cli needs to support saving
parts. Period. but mm-* is a very complex and magical library happily
used by (almost?) all the emacs mailers. It does a nice job once you
learn how to wield its magic correctly (and indeed, one of our bigger
problems is the thread-view is something it wasn't really designed for,
so we just need to figure out the best-practice for working around
that).

mm-* should continue to be used, and we need to figure out the right
technique for mapping between parts mentioned in the output of notmuch
show and the actual parts in the mm-dissect-buffer output.

I want to work on this, but I've been kind of busy and not felt like
hacking elisp lately, so hopefilly that'll turn around :/

alex

Re: [notmuch] emacs: On getting support for inline images

[Alexander Botero-Lowry]

On Wed, 10 Feb 2010 12:20:00 -0800, Carl Worth  wrote:
> For a while I've seen that I can very conveniently deal with attachments
> such as PDF files or even OpenOffice (or PowerPoint) presentations with
> the notmuch/emacs client. I simply hit 'v' and an external viewer comes
> up with the attached file. That's all very nice.
> 
Yeah, though it would b enice if we had more fine-grained control over
it, like allowing you to save a file regardless of mm-* thinks it should
get to display it or not.

> 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'.
> 
I think this is a crappy, but perfectly fine temporary fix. 

> 2. The original presentation of Mime parts could examine
>mm-inline-media-tests and directly render anything possible within
>the original presentation of the message. This would allow images to
>be viewed directly without requiring the user to press 'v'. And the
>user could configure this existing variable to control what content
>is displayed inline.
>
Yes, I think some kind of mapping of interesting parts in the message to
the mm-dissect-buffer parts and extending the text/html only inliner to
also inline those interesting parts is the right thing (tm).

Which points out a huge issue in my current inlining code, the parts
aren't actually mapped, we're basically counting on the coincidence that
the parts are in the correct place when we do the inlining, and that
seems to basically work. That being said, it's the cause of some
messages occasionally giving you a save dialog, or failing to be parsed
correctly.
 
> 3. We could move away from these various mm- functions for displaying
>MIME parts and simply add functionality to the notmuch command line
>for extracting individual MIME parts from messages, (which is
>something that a non-emacs client will likely want anyway). Then we
>can use the lower-level functions to display things directly. (For
>example, displaying an image looks as simple as calling the
>create-image and put-image functions).
>
Just talking about this on IRC. I think this is the wrong approach but
with some right bits. notmuch cli needs to support saving
parts. Period. but mm-* is a very complex and magical library happily
used by (almost?) all the emacs mailers. It does a nice job once you
learn how to wield its magic correctly (and indeed, one of our bigger
problems is the thread-view is something it wasn't really designed for,
so we just need to figure out the best-practice for working around
that).

mm-* should continue to be used, and we need to figure out the right
technique for mapping between parts mentioned in the output of notmuch
show and the actual parts in the mm-dissect-buffer output.
 
I want to work on this, but I've been kind of busy and not felt like
hacking elisp lately, so hopefilly that'll turn around :/

alex
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch

Re: [notmuch] emacs: On getting support for inline images

[Carl Worth]

On Wed, 10 Feb 2010 12:20:00 -0800, Carl Worth  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?



pgp5XiXhNv2N3.pgp
Description: PGP signature
>From 2174adf374370135061bd80db21cbd43bbac95ab Mon Sep 17 00:00:00 2001
From: Carl Worth 
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

___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch

[notmuch] emacs: On getting support for inline images

[Carl Worth]

On Wed, 10 Feb 2010 12:20:00 -0800, Carl Worth  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?

-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: 

-- next part --
A non-text attachment was scrubbed...
Name: 0001-notmuch.el-Handle-attached-images-via-an-external-vi.patch
Type: text/x-diff
Size: 1833 bytes
Desc: not available
URL: 

[notmuch] emacs: On getting support for inline images

[Carl Worth]

For a while I've seen that I can very conveniently deal with attachments
such as PDF files or even OpenOffice (or PowerPoint) presentations with
the notmuch/emacs client. I simply hit 'v' and an external viewer comes
up with the attached file. That's all very nice.

But strangely, I've also noticed that attached images don't get the same
treatment.

I investigated a bit and discovered that the images are being rendered
within emacs and inside of a temporary buffer that is being used by the
function invoked by 'v'. Before this function returns, the temporary
buffer including the nicely inline-rendered image is being killed. (And
I suspect the exact same thing is happening with encrypted messages
where hitting 'v' gets emacs to prompt for the passphrase, but then
nothing is displayed to the user.)

I was able to get images working by customizing the
mm-inline-media-tests variable. I removed the image/png clause from the
value, and now when I hit 'v' I get a nice, external image viewer as
configured in /etc/mailcap, etc.

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'.

2. The original presentation of Mime parts could examine
   mm-inline-media-tests and directly render anything possible within
   the original presentation of the message. This would allow images to
   be viewed directly without requiring the user to press 'v'. And the
   user could configure this existing variable to control what content
   is displayed inline.

3. We could move away from these various mm- functions for displaying
   MIME parts and simply add functionality to the notmuch command line
   for extracting individual MIME parts from messages, (which is
   something that a non-emacs client will likely want anyway). Then we
   can use the lower-level functions to display things directly. (For
   example, displaying an image looks as simple as calling the
   create-image and put-image functions).

Anyway, there's a lot that can be done here to make the presentation
much more usable. And of course, I'll always be glad for any help!

-Carl


pgpiehNSA73ZT.pgp
Description: PGP signature
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch

[notmuch] emacs: On getting support for inline images

[Carl Worth]

For a while I've seen that I can very conveniently deal with attachments
such as PDF files or even OpenOffice (or PowerPoint) presentations with
the notmuch/emacs client. I simply hit 'v' and an external viewer comes
up with the attached file. That's all very nice.

But strangely, I've also noticed that attached images don't get the same
treatment.

I investigated a bit and discovered that the images are being rendered
within emacs and inside of a temporary buffer that is being used by the
function invoked by 'v'. Before this function returns, the temporary
buffer including the nicely inline-rendered image is being killed. (And
I suspect the exact same thing is happening with encrypted messages
where hitting 'v' gets emacs to prompt for the passphrase, but then
nothing is displayed to the user.)

I was able to get images working by customizing the
mm-inline-media-tests variable. I removed the image/png clause from the
value, and now when I hit 'v' I get a nice, external image viewer as
configured in /etc/mailcap, etc.

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'.

2. The original presentation of Mime parts could examine
   mm-inline-media-tests and directly render anything possible within
   the original presentation of the message. This would allow images to
   be viewed directly without requiring the user to press 'v'. And the
   user could configure this existing variable to control what content
   is displayed inline.

3. We could move away from these various mm- functions for displaying
   MIME parts and simply add functionality to the notmuch command line
   for extracting individual MIME parts from messages, (which is
   something that a non-emacs client will likely want anyway). Then we
   can use the lower-level functions to display things directly. (For
   example, displaying an image looks as simple as calling the
   create-image and put-image functions).

Anyway, there's a lot that can be done here to make the presentation
much more usable. And of course, I'll always be glad for any help!

-Carl
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: