MIME decoding broken on Win NT

[Matt Armstrong <matta@geoworks.com>]

MIME decoding is broken again under Win NT (it got fixed somewhere
around 0.35, but broken somewhere since then).  Under Win NT,
default-buffer-file-coding-system is undecided-dos, not
undecided-unix.  There are places in the MIME handling within pgnus
where the default buffer-file-coding-system is used, so cr/lf
translation happens on binary stuff.

I sent myself a binary attachment consisting of two bytes: "\r\n".
Getting that to decode correctly (with the standard "1 b" key
sequence) involved this patch:


*** mm-decode.el.orig   Mon Nov 23 11:52:04 1998
--- mm-decode.el        Mon Nov 23 12:22:18 1998
***************
*** 447,453 ****
        (when (or (not (file-exists-p file))
                (yes-or-no-p (format "File %s already exists; overwrite? "
                                     file)))
!       (write-region (point-min) (point-max) file)))))

  (defun mm-pipe-part (handle)
    "Pipe HANDLE to a process."
--- 447,458 ----
        (when (or (not (file-exists-p file))
                (yes-or-no-p (format "File %s already exists; overwrite? "
                                     file)))
!       (let ((coding-system-for-write
!              (if (equal "text" (car (split-string
!                                      (car (mm-handle-type handle)) "/")))
!                  'buffer-file-coding-system
!                'binary)))
!         (write-region (point-min) (point-max) file))))))

  (defun mm-pipe-part (handle)


But I still can't decode the picture of RMS in Lars' "MIME Test One"
e-mail, so some holes still exist.

I think a better fix would be a more systematic approach -- pouring
through the MIME stuff and making sure non "text/*" parts never get
processed in a buffer where default-buffer-file-coding-system is in
effect.

I'm using NT Emacs 20.3.1, base64.el, and no mailcap stuff.

-- 
matta