I fixed it, but I need Lars ... (Was: *Group* buffer disappearance)

[Lloyd Zusman <ljz@asfast.com>]

Lloyd Zusman <ljz@asfast.com> writes:

> There's a bug that exists both in v0.35 and v0.36 whereby the *Group*
> buffer seems to mysteriously disappear under certain circumstances.
> [ ... ]

Well, I fixed the problem, but what a complex tangle of function calls
I had to go through to find it!

Also, I'm not sure if my fix is actually the best way to solve this
problem.  Lars, could you review my solution here to see if I've made
the correct assumptions in fixing it?

First of all, here's the patch which fixes the problem:

*** mm-decode.el.orig   Tue Oct 20 22:36:04 1998
--- mm-decode.el        Tue Oct 20 22:36:29 1998
***************
*** 221,227 ****
          (mm-set-buffer-file-coding-system 'no-conversion)
          (insert-buffer-substring cur)
          (funcall method)
!         (mm-handle-set-undisplayer handle (current-buffer)))
        (let* ((dir (make-temp-name (expand-file-name "emm." mm-tmp-directory)))
             (filename (mail-content-type-get
                        (mm-handle-disposition handle) 'filename))
--- 221,227 ----
          (mm-set-buffer-file-coding-system 'no-conversion)
          (insert-buffer-substring cur)
          (funcall method)
!         (mm-handle-set-undisplayer handle cur))
        (let* ((dir (make-temp-name (expand-file-name "emm." mm-tmp-directory)))
             (filename (mail-content-type-get
                        (mm-handle-disposition handle) 'filename))


Note that the problem had to do with the `(current-buffer)' call
immediately following `(funcall method)'.  When the method is
`mailcap-save-binary-file', this method causes the current buffer to
change (see below for a listing of `mailcap-save-binary-file').
Therefore, we need to use `cur' here instead of `(current-buffer)',
just like in the rest of this routine (`mm-display-external').

So far so good.  But does my solution just mask a more subtle problem?

Consider the `mailcap-save-binary-file' routine (in `mailcap.el'):

(defun mailcap-save-binary-file ()
  (goto-char (point-min))
  (let ((file (read-file-name
               "Filename to save as: "
               (or mailcap-download-directory "~/")))
        (require-final-newline nil))
    (write-region (point-min) (point-max) file)
    (kill-buffer (current-buffer))))

Note that the final line of this routine kills the current buffer,
However, when this routine is being called from within
`mm-display-external', the current buffer is one of the ` *mm*'
buffers.  Do we really want this ` *mm*' buffer to be killed as part
of the routine which saves the binary file?

If we do, then my patch is the proper fix.  However, if this ` *mm*'
buffer needs to stick around a while longer for some reason, then we
really shouldn't be using `mailcap-save-binary-file' in its current
form as the method call.

What do you think, Lars?

-- 
 Lloyd Zusman
 ljz@asfast.com