[patch] choose best looking alternative

[Colin Rafferty <craffert@ms.com>]

[-- Attachment #1: Type: text/plain, Size: 228 bytes --]

According to some RFC, a multipart/alternative is supposed to be in
order of human readable, and reverse order of prettiness when
displayed.

I just upgraded from 0.80 to 0.83, and the implied precedence order
was is reversed.


[-- Attachment #2.1: Type: text/plain, Size: 84 bytes --]

An example is this line.  It *should* be in text/enriched, but it's in
text/plain.


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2.2: Type: text/enriched, Size: 95 bytes --]

An example is this line.  It <bold>should</bold> be in text/enriched,
but it's in text/plain.


[-- Attachment #3: Type: text/plain, Size: 714 bytes --]


Anyway, here is the patch:

1999-04-22  Colin Rafferty  <colin@xemacs.org>

	* mm-decode.el (mm-preferred-alternative-precedence): Later
	handles are nicer than earlier handles.

--- mm-decode.el~	Sun Apr 18 08:44:10 1999
+++ mm-decode.el	Thu Apr 22 11:10:19 1999
@@ -586,7 +586,7 @@
 
 (defun mm-preferred-alternative-precedence (handles)
   "Return the precedence based on HANDLES and mm-discouraged-alternatives."
-  (let ((seq (mapcar (lambda (h) (car (mm-handle-type h))) handles)))
+  (let ((seq (mapcar (lambda (h) (car (mm-handle-type h))) (reverse handles))))
     (dolist (disc (reverse mm-discouraged-alternatives))
       (dolist (elem (copy-sequence seq))
 	(when (string-match disc elem)

-- 
Colin