Fred Smith <fre...@fcshome.stoneham.ma.us> [2019-07-09 22:53 -0400]:

[ ... ]

it seems to be following this recipe and decoding the html part even
though there is a perfectly readable text part, containing a :-).

does the order of statements in mailcap matter? should I change this:

text/html; lynx -dump -vikeys -raw %s; copiousoutput; nametemplate=%s.html
text/plain; copiousoutput

to this:

text/plain; copiousoutput
text/html; lynx -dump -vikeys -raw %s; copiousoutput; nametemplate=%s.html

Or is th is problem just because Outlook is broken and instead of
issuing a font change should just embed the proper Unicode character?

The order of the entries in mailcap should not matter. When there are
multiple parts, Mutt decides which part to display based on the value
of the alternative_order setting. This is, for example, what I have in
my configuration, and it gives priority first to text/enriched, then
to text/plain, and only then to text/html.

alternative_order text/enriched text/plain text/html

Mutt will display the first type that is available in a mail. You can
read more about in the manual.

--- Amit

Reply via email to