--- /dev/null
+Return-Path: <alex.boterolowry@gmail.com>\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 37C55431FC0\r
+ for <notmuch@notmuchmail.org>; Wed, 10 Feb 2010 13:52:46 -0800 (PST)\r
+X-Virus-Scanned: Debian amavisd-new at olra.theworths.org\r
+X-Spam-Flag: NO\r
+X-Spam-Score: -0.214\r
+X-Spam-Level: \r
+X-Spam-Status: No, score=-0.214 tagged_above=-999 required=5\r
+ tests=[AWL=-0.216, BAYES_50=0.001, UNPARSEABLE_RELAY=0.001]\r
+ autolearn=ham\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 7sFeNslDMB1k for <notmuch@notmuchmail.org>;\r
+ Wed, 10 Feb 2010 13:52:45 -0800 (PST)\r
+Received: from mail-fx0-f217.google.com (mail-fx0-f217.google.com\r
+ [209.85.220.217])\r
+ by olra.theworths.org (Postfix) with ESMTP id ED00D431FAE\r
+ for <notmuch@notmuchmail.org>; Wed, 10 Feb 2010 13:52:44 -0800 (PST)\r
+Received: by fxm9 with SMTP id 9so201100fxm.30\r
+ for <notmuch@notmuchmail.org>; Wed, 10 Feb 2010 13:52:44 -0800 (PST)\r
+DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;\r
+ h=domainkey-signature:received:received:received:from:to:subject\r
+ :in-reply-to:references:date:message-id:mime-version:content-type;\r
+ bh=btqoCGxU4TG6k1GmCWEpzsTq7T/8z8LLnV+EoLEu3k0=;\r
+ b=G9w5pg6zU1JRLHJPvr2Aqd6cGIAs/2Y36y+8z/Re3P8I0INNa758jAopSfvzUtany9\r
+ mtkDL0texCKs3dCw0JhJTwUUiGhdmGJKY5iI1ZSbG3/C3cTEvhUXglLYnNbk73iM4xfb\r
+ nQG3/r7JkgBRNzXr8ypFaaDiNSE4OmEuJU7WU=\r
+DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma;\r
+ h=from:to:subject:in-reply-to:references:date:message-id:mime-version\r
+ :content-type;\r
+ b=dYNekHUztwFvqKiWkGDH8ceKY0SiU6JNphaNOTvMk6ADf98Rqf8CYRRmrWQU/AXCrq\r
+ 3ChKgaK13DS9wH02zeIr4JRbkgRDa04asJX6gVuPvqwKDKL1FEAqV+5OXrLs64d/VCNT\r
+ RbF9f3hEPmSY8Gg39xIubvf6+zc4KNxZFokaI=\r
+Received: by 10.87.69.17 with SMTP id w17mr4155170fgk.41.1265838763931;\r
+ Wed, 10 Feb 2010 13:52:43 -0800 (PST)\r
+Received: from fortitudo (nat09.metaweb.com [208.68.111.136])\r
+ by mx.google.com with ESMTPS id 16sm846399fxm.0.2010.02.10.13.52.38\r
+ (version=TLSv1/SSLv3 cipher=RC4-MD5);\r
+ Wed, 10 Feb 2010 13:52:40 -0800 (PST)\r
+Received: from alexbl (uid 1001) (envelope-from\r
+ alexbl@fortitudo.i-did-not-set--mail-host-address--so-tickle-me)\r
+ id a095 by fortitudo (DragonFly Mail Agent)\r
+ Wed, 10 Feb 2010 13:53:53 -0800\r
+From: Alexander Botero-Lowry <alex.boterolowry@gmail.com>\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 13:53:52 -0800\r
+Message-ID:\r
+ <866364g3kf.fsf@fortitudo.i-did-not-set--mail-host-address--so-tickle-me>\r
+MIME-Version: 1.0\r
+Content-Type: text/plain; charset=us-ascii\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: Wed, 10 Feb 2010 21:52:46 -0000\r
+\r
+On Wed, 10 Feb 2010 12:20:00 -0800, Carl Worth <cworth@cworth.org> wrote:\r
+> For a while I've seen that I can very conveniently deal with attachments\r
+> such as PDF files or even OpenOffice (or PowerPoint) presentations with\r
+> the notmuch/emacs client. I simply hit 'v' and an external viewer comes\r
+> up with the attached file. That's all very nice.\r
+> \r
+Yeah, though it would b enice if we had more fine-grained control over\r
+it, like allowing you to save a file regardless of mm-* thinks it should\r
+get to display it or not.\r
+\r
+> Here are some ideas for possible (and independent) fixes:\r
+> \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
+I think this is a crappy, but perfectly fine temporary fix. \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
+Yes, I think some kind of mapping of interesting parts in the message to\r
+the mm-dissect-buffer parts and extending the text/html only inliner to\r
+also inline those interesting parts is the right thing (tm).\r
+\r
+Which points out a huge issue in my current inlining code, the parts\r
+aren't actually mapped, we're basically counting on the coincidence that\r
+the parts are in the correct place when we do the inlining, and that\r
+seems to basically work. That being said, it's the cause of some\r
+messages occasionally giving you a save dialog, or failing to be parsed\r
+correctly.\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
+Just talking about this on IRC. I think this is the wrong approach but\r
+with some right bits. notmuch cli needs to support saving\r
+parts. Period. but mm-* is a very complex and magical library happily\r
+used by (almost?) all the emacs mailers. It does a nice job once you\r
+learn how to wield its magic correctly (and indeed, one of our bigger\r
+problems is the thread-view is something it wasn't really designed for,\r
+so we just need to figure out the best-practice for working around\r
+that).\r
+\r
+mm-* should continue to be used, and we need to figure out the right\r
+technique for mapping between parts mentioned in the output of notmuch\r
+show and the actual parts in the mm-dissect-buffer output.\r
+ \r
+I want to work on this, but I've been kind of busy and not felt like\r
+hacking elisp lately, so hopefilly that'll turn around :/\r
+\r
+alex\r
projects / notmuch-archives.git / commitdiff