Re: [notmuch] emacs: On getting support for inline images
authormicah anderson <micah@riseup.net>
Thu, 11 Feb 2010 03:57:41 +0000 (22:57 +1900)
committerW. Trevor King <wking@tremily.us>
Fri, 7 Nov 2014 17:36:10 +0000 (09:36 -0800)
b4/b8e693e6113e816976133f91fa0c3a078d70e4 [new file with mode: 0644]

diff --git a/b4/b8e693e6113e816976133f91fa0c3a078d70e4 b/b4/b8e693e6113e816976133f91fa0c3a078d70e4
new file mode 100644 (file)
index 0000000..593aa90
--- /dev/null
@@ -0,0 +1,135 @@
+Return-Path: <micah@riseup.net>\r
+X-Original-To: notmuch@notmuchmail.org\r
+Delivered-To: notmuch@notmuchmail.org\r
+Received: from localhost (localhost [127.0.0.1])\r
+       by olra.theworths.org (Postfix) with ESMTP id D6393431FAE\r
+       for <notmuch@notmuchmail.org>; Wed, 10 Feb 2010 19:57:20 -0800 (PST)\r
+X-Virus-Scanned: Debian amavisd-new at olra.theworths.org\r
+X-Spam-Flag: NO\r
+X-Spam-Score: -0.778\r
+X-Spam-Level: \r
+X-Spam-Status: No, score=-0.778 tagged_above=-999 required=5 tests=[AWL=0.220,\r
+       BAYES_50=0.001, RCVD_IN_DNSWL_LOW=-1, UNPARSEABLE_RELAY=0.001]\r
+       autolearn=unavailable\r
+Received: from olra.theworths.org ([127.0.0.1])\r
+       by localhost (olra.theworths.org [127.0.0.1]) (amavisd-new, port 10024)\r
+       with ESMTP id seMquq-n-m-S for <notmuch@notmuchmail.org>;\r
+       Wed, 10 Feb 2010 19:57:19 -0800 (PST)\r
+Received: from mx1.riseup.net (mx1.riseup.net [204.13.164.18])\r
+       by olra.theworths.org (Postfix) with ESMTP id D9967431FBC\r
+       for <notmuch@notmuchmail.org>; Wed, 10 Feb 2010 19:57:18 -0800 (PST)\r
+Received: from [127.0.0.1] (localhost [127.0.0.1])\r
+       (Authenticated sender: micah@mx1.riseup.net)\r
+       with ESMTPSA id C59F825F078\r
+Received: by lillypad (Postfix, from userid 1000)\r
+       id 9C58A4A8167; Wed, 10 Feb 2010 22:57:45 -0500 (EST)\r
+From: micah anderson <micah@riseup.net>\r
+To: Carl Worth <cworth@cworth.org>, notmuch@notmuchmail.org\r
+In-Reply-To: <87vde4derz.fsf@yoom.home.cworth.org>\r
+References: <87vde4derz.fsf@yoom.home.cworth.org>\r
+Date: Wed, 10 Feb 2010 22:57:41 -0500\r
+Message-ID: <87d40ca0ga.fsf@lillypad.riseup.net>\r
+MIME-Version: 1.0\r
+Content-Type: multipart/signed; boundary="=-=-=";\r
+       micalg=pgp-sha512; protocol="application/pgp-signature"\r
+X-Virus-Scanned: clamav-milter 0.95.3 at mx1\r
+X-Virus-Status: Clean\r
+Subject: Re: [notmuch] emacs: On getting support for inline images\r
+X-BeenThere: notmuch@notmuchmail.org\r
+X-Mailman-Version: 2.1.13\r
+Precedence: list\r
+List-Id: "Use and development of the notmuch mail system."\r
+       <notmuch.notmuchmail.org>\r
+List-Unsubscribe: <http://notmuchmail.org/mailman/options/notmuch>,\r
+       <mailto:notmuch-request@notmuchmail.org?subject=unsubscribe>\r
+List-Archive: <http://notmuchmail.org/pipermail/notmuch>\r
+List-Post: <mailto:notmuch@notmuchmail.org>\r
+List-Help: <mailto:notmuch-request@notmuchmail.org?subject=help>\r
+List-Subscribe: <http://notmuchmail.org/mailman/listinfo/notmuch>,\r
+       <mailto:notmuch-request@notmuchmail.org?subject=subscribe>\r
+X-List-Received-Date: Thu, 11 Feb 2010 03:57:21 -0000\r
+\r
+--=-=-=\r
+Content-Transfer-Encoding: quoted-printable\r
+\r
+\r
+On Wed, 10 Feb 2010 12:20:00 -0800, Carl Worth <cworth@cworth.org> wrote:\r
+> I investigated a bit and discovered that the images are being rendered\r
+> within emacs and inside of a temporary buffer that is being used by the\r
+> function invoked by 'v'. Before this function returns, the temporary\r
+> buffer including the nicely inline-rendered image is being killed. (And\r
+> I suspect the exact same thing is happening with encrypted messages\r
+> where hitting 'v' gets emacs to prompt for the passphrase, but then\r
+> nothing is displayed to the user.)\r
+>=20\r
+> I was able to get images working by customizing the\r
+> mm-inline-media-tests variable. I removed the image/png clause from the\r
+> value, and now when I hit 'v' I get a nice, external image viewer as\r
+> configured in /etc/mailcap, etc.\r
+>=20\r
+> Here are some ideas for possible (and independent) fixes:\r
+>=20\r
+> 1. With the current setup, we know we are using a temporary buffer that\r
+>    the user won't see, so notmuch could temporarily set\r
+>    mm-inline-media-tests to nil forcing everything to use external\r
+>    viewers when the user presses 'v'.\r
+\r
+This would leave encrypted messages in a weird spot. What external\r
+viewer would you want to be launched when you press 'v' on an encrypted\r
+message? I'd like it to be emacs myself, and even better I want it to be\r
+in notmuch/mml-mode so I can reply to it and get quoting. Although this\r
+option seems like the easiest solution, it avoids the problem, and\r
+unfortunately not very well. Emacs can display images and PDFs fine too,\r
+it just can't do openoffice documents, yet ;)\r
+\r
+> 2. The original presentation of Mime parts could examine\r
+>    mm-inline-media-tests and directly render anything possible within\r
+>    the original presentation of the message. This would allow images to\r
+>    be viewed directly without requiring the user to press 'v'. And the\r
+>    user could configure this existing variable to control what content\r
+>    is displayed inline.\r
+\r
+This seems like the right way to handle things in the emacs mode.\r
+\r
+> 3. We could move away from these various mm- functions for displaying\r
+>    MIME parts and simply add functionality to the notmuch command line\r
+>    for extracting individual MIME parts from messages, (which is\r
+>    something that a non-emacs client will likely want anyway). Then we\r
+>    can use the lower-level functions to display things directly. (For\r
+>    example, displaying an image looks as simple as calling the\r
+>    create-image and put-image functions).\r
+\r
+I would think that the mm functions are probably pretty battle-tested\r
+and have been in a lot of very careful honing over the years. They\r
+probably do the right thing, and do it well because a lot of work has\r
+gone into getting them right. I'm sure there is a big here and there,\r
+but still it seems like it would be a shame not to use something that\r
+has a pretty full feature-set.=20\r
+\r
+On the other-hand, I see your point about non-emacs clients, and the\r
+command-line having the ability to parse our MIME parts. Perhaps there\r
+is room for both to play?\r
+\r
+micah\r
+\r
+--=-=-=\r
+Content-Type: application/pgp-signature\r
+\r
+-----BEGIN PGP SIGNATURE-----\r
+Version: GnuPG v1.4.10 (GNU/Linux)\r
+\r
+iQIcBAEBCgAGBQJLc4A1AAoJEIy/mjIoYaeQ2eIP/0mDwavmZoJ6jI7Z9VKUmePp\r
+IjCMb1SFIodFeC4k+4yRMh7XO4U4kty4eYCuDVajaf+yPLUqFHPVBrnkfhp3+WIM\r
+tA0ae0iDV2eEsonIIQevyeY5Vsl/1Wu/9jdKmi6fwl/uyCD5plY7D70L3e0ZYFte\r
+1SPN/JMC/MRt+nIV0+oe1GoWkB2ebfEkdTc818xFu1E4xSNMV4uS55sxiNrdTQrG\r
+V2dc0R3DJ6qpNYiaVHXDdxuZnf012YvnNLEALJD8B+YQ53MYIo/SyKyA1YLxwPH9\r
+UsYmLJIArdZXzzg+MzbK6xY7QvQfkfrqPF6hW0dHX+Zaw3/8xGIL927smvfQqXPq\r
+13B/dxIMu100qI3mczOOeV0Ukhwh/Ew5V9PZRQu5r0PVjZBG1VAK/gOMYiJErf7Y\r
+Y/4LvLSq/qZ7fDXKnfSpt9/TzPAFaE5uTsCF5BGDHuWZCYboxP5munAcACHeALKJ\r
+epvWGlw1x7mWNrnlWjICbyMCx8Ocs7+pHLG45KF3RLGiHGex9ercqvz1NKVYxpyg\r
+e9AFNSfSF1GgZNaVlrk3os+GCTcxK3hW3cqCWZcb964QI/zgMV5sYtAoizQVskcJ\r
+IoOyX1pIdKNrfSoRnTS16sccpy2PVPKG/Yr91uBX6FXLrR8EwaG9kl1rfG6m/GGx\r
+a5H6CLmOBooFrF3DGqH8\r
+=cZn8\r
+-----END PGP SIGNATURE-----\r
+--=-=-=--\r