b4/b8e693e6113e816976133f91fa0c3a078d70e4

   1 Return-Path: <micah@riseup.net>\r
   2 X-Original-To: notmuch@notmuchmail.org\r
   3 Delivered-To: notmuch@notmuchmail.org\r
   4 Received: from localhost (localhost [127.0.0.1])\r
   5         by olra.theworths.org (Postfix) with ESMTP id D6393431FAE\r
   6         for <notmuch@notmuchmail.org>; Wed, 10 Feb 2010 19:57:20 -0800 (PST)\r
   7 X-Virus-Scanned: Debian amavisd-new at olra.theworths.org\r
   8 X-Spam-Flag: NO\r
   9 X-Spam-Score: -0.778\r
  10 X-Spam-Level: \r
  11 X-Spam-Status: No, score=-0.778 tagged_above=-999 required=5 tests=[AWL=0.220,\r
  12         BAYES_50=0.001, RCVD_IN_DNSWL_LOW=-1, UNPARSEABLE_RELAY=0.001]\r
  13         autolearn=unavailable\r
  14 Received: from olra.theworths.org ([127.0.0.1])\r
  15         by localhost (olra.theworths.org [127.0.0.1]) (amavisd-new, port 10024)\r
  16         with ESMTP id seMquq-n-m-S for <notmuch@notmuchmail.org>;\r
  17         Wed, 10 Feb 2010 19:57:19 -0800 (PST)\r
  18 Received: from mx1.riseup.net (mx1.riseup.net [204.13.164.18])\r
  19         by olra.theworths.org (Postfix) with ESMTP id D9967431FBC\r
  20         for <notmuch@notmuchmail.org>; Wed, 10 Feb 2010 19:57:18 -0800 (PST)\r
  21 Received: from [127.0.0.1] (localhost [127.0.0.1])\r
  22         (Authenticated sender: micah@mx1.riseup.net)\r
  23         with ESMTPSA id C59F825F078\r
  24 Received: by lillypad (Postfix, from userid 1000)\r
  25         id 9C58A4A8167; Wed, 10 Feb 2010 22:57:45 -0500 (EST)\r
  26 From: micah anderson <micah@riseup.net>\r
  27 To: Carl Worth <cworth@cworth.org>, notmuch@notmuchmail.org\r
  28 In-Reply-To: <87vde4derz.fsf@yoom.home.cworth.org>\r
  29 References: <87vde4derz.fsf@yoom.home.cworth.org>\r
  30 Date: Wed, 10 Feb 2010 22:57:41 -0500\r
  31 Message-ID: <87d40ca0ga.fsf@lillypad.riseup.net>\r
  32 MIME-Version: 1.0\r
  33 Content-Type: multipart/signed; boundary="=-=-=";\r
  34         micalg=pgp-sha512; protocol="application/pgp-signature"\r
  35 X-Virus-Scanned: clamav-milter 0.95.3 at mx1\r
  36 X-Virus-Status: Clean\r
  37 Subject: Re: [notmuch] emacs: On getting support for inline images\r
  38 X-BeenThere: notmuch@notmuchmail.org\r
  39 X-Mailman-Version: 2.1.13\r
  40 Precedence: list\r
  41 List-Id: "Use and development of the notmuch mail system."\r
  42         <notmuch.notmuchmail.org>\r
  43 List-Unsubscribe: <http://notmuchmail.org/mailman/options/notmuch>,\r
  44         <mailto:notmuch-request@notmuchmail.org?subject=unsubscribe>\r
  45 List-Archive: <http://notmuchmail.org/pipermail/notmuch>\r
  46 List-Post: <mailto:notmuch@notmuchmail.org>\r
  47 List-Help: <mailto:notmuch-request@notmuchmail.org?subject=help>\r
  48 List-Subscribe: <http://notmuchmail.org/mailman/listinfo/notmuch>,\r
  49         <mailto:notmuch-request@notmuchmail.org?subject=subscribe>\r
  50 X-List-Received-Date: Thu, 11 Feb 2010 03:57:21 -0000\r
  51 \r
  52 --=-=-=\r
  53 Content-Transfer-Encoding: quoted-printable\r
  54 \r
  55 \r
  56 On Wed, 10 Feb 2010 12:20:00 -0800, Carl Worth <cworth@cworth.org> wrote:\r
  57 > I investigated a bit and discovered that the images are being rendered\r
  58 > within emacs and inside of a temporary buffer that is being used by the\r
  59 > function invoked by 'v'. Before this function returns, the temporary\r
  60 > buffer including the nicely inline-rendered image is being killed. (And\r
  61 > I suspect the exact same thing is happening with encrypted messages\r
  62 > where hitting 'v' gets emacs to prompt for the passphrase, but then\r
  63 > nothing is displayed to the user.)\r
  64 >=20\r
  65 > I was able to get images working by customizing the\r
  66 > mm-inline-media-tests variable. I removed the image/png clause from the\r
  67 > value, and now when I hit 'v' I get a nice, external image viewer as\r
  68 > configured in /etc/mailcap, etc.\r
  69 >=20\r
  70 > Here are some ideas for possible (and independent) fixes:\r
  71 >=20\r
  72 > 1. With the current setup, we know we are using a temporary buffer that\r
  73 >    the user won't see, so notmuch could temporarily set\r
  74 >    mm-inline-media-tests to nil forcing everything to use external\r
  75 >    viewers when the user presses 'v'.\r
  76 \r
  77 This would leave encrypted messages in a weird spot. What external\r
  78 viewer would you want to be launched when you press 'v' on an encrypted\r
  79 message? I'd like it to be emacs myself, and even better I want it to be\r
  80 in notmuch/mml-mode so I can reply to it and get quoting. Although this\r
  81 option seems like the easiest solution, it avoids the problem, and\r
  82 unfortunately not very well. Emacs can display images and PDFs fine too,\r
  83 it just can't do openoffice documents, yet ;)\r
  84 \r
  85 > 2. The original presentation of Mime parts could examine\r
  86 >    mm-inline-media-tests and directly render anything possible within\r
  87 >    the original presentation of the message. This would allow images to\r
  88 >    be viewed directly without requiring the user to press 'v'. And the\r
  89 >    user could configure this existing variable to control what content\r
  90 >    is displayed inline.\r
  91 \r
  92 This seems like the right way to handle things in the emacs mode.\r
  93 \r
  94 > 3. We could move away from these various mm- functions for displaying\r
  95 >    MIME parts and simply add functionality to the notmuch command line\r
  96 >    for extracting individual MIME parts from messages, (which is\r
  97 >    something that a non-emacs client will likely want anyway). Then we\r
  98 >    can use the lower-level functions to display things directly. (For\r
  99 >    example, displaying an image looks as simple as calling the\r
 100 >    create-image and put-image functions).\r
 101 \r
 102 I would think that the mm functions are probably pretty battle-tested\r
 103 and have been in a lot of very careful honing over the years. They\r
 104 probably do the right thing, and do it well because a lot of work has\r
 105 gone into getting them right. I'm sure there is a big here and there,\r
 106 but still it seems like it would be a shame not to use something that\r
 107 has a pretty full feature-set.=20\r
 108 \r
 109 On the other-hand, I see your point about non-emacs clients, and the\r
 110 command-line having the ability to parse our MIME parts. Perhaps there\r
 111 is room for both to play?\r
 112 \r
 113 micah\r
 114 \r
 115 --=-=-=\r
 116 Content-Type: application/pgp-signature\r
 117 \r
 118 -----BEGIN PGP SIGNATURE-----\r
 119 Version: GnuPG v1.4.10 (GNU/Linux)\r
 120 \r
 121 iQIcBAEBCgAGBQJLc4A1AAoJEIy/mjIoYaeQ2eIP/0mDwavmZoJ6jI7Z9VKUmePp\r
 122 IjCMb1SFIodFeC4k+4yRMh7XO4U4kty4eYCuDVajaf+yPLUqFHPVBrnkfhp3+WIM\r
 123 tA0ae0iDV2eEsonIIQevyeY5Vsl/1Wu/9jdKmi6fwl/uyCD5plY7D70L3e0ZYFte\r
 124 1SPN/JMC/MRt+nIV0+oe1GoWkB2ebfEkdTc818xFu1E4xSNMV4uS55sxiNrdTQrG\r
 125 V2dc0R3DJ6qpNYiaVHXDdxuZnf012YvnNLEALJD8B+YQ53MYIo/SyKyA1YLxwPH9\r
 126 UsYmLJIArdZXzzg+MzbK6xY7QvQfkfrqPF6hW0dHX+Zaw3/8xGIL927smvfQqXPq\r
 127 13B/dxIMu100qI3mczOOeV0Ukhwh/Ew5V9PZRQu5r0PVjZBG1VAK/gOMYiJErf7Y\r
 128 Y/4LvLSq/qZ7fDXKnfSpt9/TzPAFaE5uTsCF5BGDHuWZCYboxP5munAcACHeALKJ\r
 129 epvWGlw1x7mWNrnlWjICbyMCx8Ocs7+pHLG45KF3RLGiHGex9ercqvz1NKVYxpyg\r
 130 e9AFNSfSF1GgZNaVlrk3os+GCTcxK3hW3cqCWZcb964QI/zgMV5sYtAoizQVskcJ\r
 131 IoOyX1pIdKNrfSoRnTS16sccpy2PVPKG/Yr91uBX6FXLrR8EwaG9kl1rfG6m/GGx\r
 132 a5H6CLmOBooFrF3DGqH8\r
 133 =cZn8\r
 134 -----END PGP SIGNATURE-----\r
 135 --=-=-=--\r