OK - I figured out the problem.
It appears that there was an (undocumented) change to the variable vm-included-mime-types
In earlier versions it defaulted to:
("text/plain" "text/enriched" "message/rfc822")
So, I then added "text/html" and got the list I wanted.
In the new version, it defaults to nil which has a new meaning now, specifically "include all types that
are handled by VM's MIME decoding mechanism."
So, when I just added "text/html", I got the isolated list of ("text/html") which explains the above behavior more-or-less.
This time I checked in the NEWS file and this change was NOT documented. I really can't emphasize enough the importance of not breaking old behaviors unless such changes are:
(A) necessary or significant improvements
and (B) well-documented
and (C) done in a way that minimizes the chance of breakage.
In this case, I would suggest that none of the 3 conditions were satisfied. I'm sorry if I come across as a nag or critic here but I really do care about VM and about all the work everybody is putting into it, but I think that VM in general is at the stage where it is quite stable and mature (except for perhaps IMAP and other new email functionality) so that the bar for changes in core working code needs to be pretty high to justify fixing something that "ain't" broken.
OK - I figured out the problem. mime-types
It appears that there was an (undocumented) change to the variable vm-included-
In earlier versions it defaulted to:
("text/plain" "text/enriched" "message/rfc822")
So, I then added "text/html" and got the list I wanted.
In the new version, it defaults to nil which has a new meaning now, specifically "include all types that
are handled by VM's MIME decoding mechanism."
So, when I just added "text/html", I got the isolated list of ("text/html") which explains the above behavior more-or-less.
This time I checked in the NEWS file and this change was NOT documented. I really can't emphasize enough the importance of not breaking old behaviors unless such changes are:
(A) necessary or significant improvements
and (B) well-documented
and (C) done in a way that minimizes the chance of breakage.
In this case, I would suggest that none of the 3 conditions were satisfied. I'm sorry if I come across as a nag or critic here but I really do care about VM and about all the work everybody is putting into it, but I think that VM in general is at the stage where it is quite stable and mature (except for perhaps IMAP and other new email functionality) so that the bar for changes in core working code needs to be pretty high to justify fixing something that "ain't" broken.