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