Re: mailcap entry for image/jpeg not found

[Kyle Wheeler <kyle-mutt@xxxxxxxxxxxxxx>]

-----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-----