Kyle, you rock! Many thanks for your detailed and explanatory email. :)
-j On Wed, Jun 10, 2009 at 3:49 PM, Kyle Wheeler<[email protected]> wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA256 > > On Wednesday, June 10 at 03:17 PM, quoth James: >> This is a weird one. > > :) Not as weird as you'd think, once you understand what's going on. > >> When I open an email that attached jpeg images, I get a "mailcap >> entry for image/jpeg not found" message on the mutt status bar. > > In other words, what happened is that mutt tried to display the jpeg > images INLINE (i.e. in the pager, as text). It probably did that > because you added an "auto_view image/jpeg" or "auto_view image/*" (or > something similar) to your muttrc. > > Here's what the muttrc man page has to say on the subject: > > auto_view type[/subtype] [ ... ] > unauto_view type[/subtype] [ ... ] > This command permits you to specify that mutt should > automatically convert the given MIME types to text/plain when > displaying messages. For this to work, there must be a > mailcap(5) entry for the given MIME type with the > copiousoutput flag set. A subtype of "*" matches any subtype, > as does an empty subtype. > > Did you catch that? Mutt is looking for a mailcap entry with the > "copiousoutput" flag. Why? Because mutt is attempting to display the > attachment INLINE, and the only thing it knows how to display inline > is some form of text. This is commonly used for things like doc files > (which can be rendered to text with various utilities) and html files > (which can be rendered to text with various utilities). The only way > this could work with images is to use some libascii tool to convert > the image to ascii-art. > >> Hitting 'v', and then 'enter' on one of the images, however, >> successfully opens the jpeg image. > > Right, because then mutt isn't attempting to display the image inline, > and has the freedom to use just about any relevant mailcap entry. > >> Thoughts? Clearly the mailcap entry is correct if I can open the >> image after hitting 'v' and selecting the jpeg. > > Strictly speaking, that does *NOT* prove that the mailcap entry is > correct, merely that the entry is functional. It may be working for > reasons you don't understand (no disrespect intended). > > Put it this way: mailcap entries are more complicated than simply > defining a command to use to view a given mime-type. Among other > complex tricks, you can specify particular types of output. The > "copiousoutput" flag, for example, means "this command produces its > output as text on stdout". > > The reason that mailcap entries can specify what type of output they > produce is that some situations require particular types of output. > This is a key example: viewing attachments inline in mutt's pager > requires a plain text version of the attachment, which means mutt will > only accept mailcap entries with the "copiousoutput" flag (i.e. those > that promise to provide text). > > Of course, you can *subvert* the idea in order to get those files > displayed via `display` even though it's supposed to be displayed > inline. But that requires writing a small script and using that as > your mailcap entry. > > Does that make sense? > > ~Kyle > - -- > The only way to oppose a bad idea is to replace it with a good idea. > -- Jack Kemp > -----BEGIN PGP SIGNATURE----- > Comment: Thank you for using encryption! > > iQIcBAEBCAAGBQJKMA48AAoJECuveozR/AWemYsQAJvMey52+E9h5AvocokQkn4T > M3C4NZasww8u8N5fsgXf1Br9gGTz+cDioUajQLVyVJghqNZw0Sk7AvpJU0CCs5Un > 0MeP9MUkQyOoEV54y+dB28a0GPP0QJCzDBVYzKZ6o3B58SkLtSkBTFQDzJNagtKe > 28T5uyOODha0S+2N4lrUqs4aY+Y6gYwOsXqvqlcANaPtrMRlaKeU4DIfzBYk33VJ > xdj/0mb5p8Wk/fsFpQkuZWkk95zdGNUQuwENuiDybzaFlgQLn09VBE1JFOfoK1A+ > bi1sv/Y1qPCSulW7uXPo4SU4xocn+1lf6U9gWbw0LG8o/CcZw5eoYmQJXPL1Qtt/ > VSxmKQn66zuY4FbwaSJFAljsEg8X65VxVzxpbtM+iPwMwhnlS+LIba+c1J/L5Lv0 > fx5KDCTpv3RFRNzf58pl+nitGvImt6pkht+4DjcgnqOubOXlj8/XzTnJSmSaeD44 > f3l6E5kvIdSZZXRC4dEQoKbElFOfJ2pqDyr9rant4+3TMKmbA7UPPgCGAXbCH1mX > Tk3MYhYOcTWxwwdsfr1ZZe3nfUpLW1oSx/JUIAuuz8PLwMQHYGHhqeWCBjBjXzmB > u2T1KH9G4hC2DpGWU5pg3KhKoUImBVs41l1OCx9rcUbTmBAsVDq/au0EXBOkA6G/ > Ll0p6DTZ2QZchF8pvb1K > =I4LX > -----END PGP SIGNATURE-----
