From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from localhost (localhost [127.0.0.1]) by olra.theworths.org (Postfix) with ESMTP id D6393431FAE for ; Wed, 10 Feb 2010 19:57:20 -0800 (PST) X-Virus-Scanned: Debian amavisd-new at olra.theworths.org X-Spam-Flag: NO X-Spam-Score: -0.778 X-Spam-Level: X-Spam-Status: No, score=-0.778 tagged_above=-999 required=5 tests=[AWL=0.220, BAYES_50=0.001, RCVD_IN_DNSWL_LOW=-1, UNPARSEABLE_RELAY=0.001] autolearn=unavailable Received: from olra.theworths.org ([127.0.0.1]) by localhost (olra.theworths.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id seMquq-n-m-S for ; Wed, 10 Feb 2010 19:57:19 -0800 (PST) Received: from mx1.riseup.net (mx1.riseup.net [204.13.164.18]) by olra.theworths.org (Postfix) with ESMTP id D9967431FBC for ; Wed, 10 Feb 2010 19:57:18 -0800 (PST) Received: from [127.0.0.1] (localhost [127.0.0.1]) (Authenticated sender: micah@mx1.riseup.net) with ESMTPSA id C59F825F078 Received: by lillypad (Postfix, from userid 1000) id 9C58A4A8167; Wed, 10 Feb 2010 22:57:45 -0500 (EST) From: micah anderson To: Carl Worth , notmuch@notmuchmail.org In-Reply-To: <87vde4derz.fsf@yoom.home.cworth.org> References: <87vde4derz.fsf@yoom.home.cworth.org> Date: Wed, 10 Feb 2010 22:57:41 -0500 Message-ID: <87d40ca0ga.fsf@lillypad.riseup.net> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha512; protocol="application/pgp-signature" X-Virus-Scanned: clamav-milter 0.95.3 at mx1 X-Virus-Status: Clean Subject: Re: emacs: On getting support for inline images X-BeenThere: notmuch@notmuchmail.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: "Use and development of the notmuch mail system." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Feb 2010 03:57:21 -0000 --=-=-= Content-Transfer-Encoding: quoted-printable 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.) >=20 > 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. >=20 > Here are some ideas for possible (and independent) fixes: >=20 > 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.=20 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 --=-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) iQIcBAEBCgAGBQJLc4A1AAoJEIy/mjIoYaeQ2eIP/0mDwavmZoJ6jI7Z9VKUmePp IjCMb1SFIodFeC4k+4yRMh7XO4U4kty4eYCuDVajaf+yPLUqFHPVBrnkfhp3+WIM tA0ae0iDV2eEsonIIQevyeY5Vsl/1Wu/9jdKmi6fwl/uyCD5plY7D70L3e0ZYFte 1SPN/JMC/MRt+nIV0+oe1GoWkB2ebfEkdTc818xFu1E4xSNMV4uS55sxiNrdTQrG V2dc0R3DJ6qpNYiaVHXDdxuZnf012YvnNLEALJD8B+YQ53MYIo/SyKyA1YLxwPH9 UsYmLJIArdZXzzg+MzbK6xY7QvQfkfrqPF6hW0dHX+Zaw3/8xGIL927smvfQqXPq 13B/dxIMu100qI3mczOOeV0Ukhwh/Ew5V9PZRQu5r0PVjZBG1VAK/gOMYiJErf7Y Y/4LvLSq/qZ7fDXKnfSpt9/TzPAFaE5uTsCF5BGDHuWZCYboxP5munAcACHeALKJ epvWGlw1x7mWNrnlWjICbyMCx8Ocs7+pHLG45KF3RLGiHGex9ercqvz1NKVYxpyg e9AFNSfSF1GgZNaVlrk3os+GCTcxK3hW3cqCWZcb964QI/zgMV5sYtAoizQVskcJ IoOyX1pIdKNrfSoRnTS16sccpy2PVPKG/Yr91uBX6FXLrR8EwaG9kl1rfG6m/GGx a5H6CLmOBooFrF3DGqH8 =cZn8 -----END PGP SIGNATURE----- --=-=-=--