From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.io/gmane.emacs.gnus.general/18002 Path: main.gmane.org!not-for-mail From: Lloyd Zusman Newsgroups: gmane.emacs.gnus.general Subject: I fixed it, but I need Lars ... (Was: *Group* buffer disappearance) Date: 20 Oct 1998 22:58:47 -400 Sender: owner-ding@hpc.uh.edu Message-ID: References: NNTP-Posting-Host: coloc-standby.netfonds.no X-Trace: main.gmane.org 1035156600 3808 80.91.224.250 (20 Oct 2002 23:30:00 GMT) X-Complaints-To: usenet@main.gmane.org NNTP-Posting-Date: Sun, 20 Oct 2002 23:30:00 +0000 (UTC) Cc: larsi@ifi.uio.no Return-Path: Original-Received: from fisher.math.uh.edu (fisher.math.uh.edu [129.7.128.35]) by sclp3.sclp.com (8.8.5/8.8.5) with ESMTP id XAA09622 for ; Tue, 20 Oct 1998 23:05:31 -0400 (EDT) Original-Received: from sina.hpc.uh.edu (lists@Sina.HPC.UH.EDU [129.7.3.5]) by fisher.math.uh.edu (8.9.1/8.9.1) with ESMTP id VAB10678; Tue, 20 Oct 1998 21:59:36 -0500 (CDT) Original-Received: by sina.hpc.uh.edu (TLB v0.09a (1.20 tibbs 1996/10/09 22:03:07)); Tue, 20 Oct 1998 21:59:23 -0500 (CDT) Original-Received: from sclp3.sclp.com (root@sclp3.sclp.com [209.195.19.139]) by sina.hpc.uh.edu (8.7.3/8.7.3) with ESMTP id VAA16393 for ; Tue, 20 Oct 1998 21:59:12 -0500 (CDT) Original-Received: from ljz.asfast.net (gnus@ljz.asfast.net [205.230.75.82]) by sclp3.sclp.com (8.8.5/8.8.5) with ESMTP id WAA09376; Tue, 20 Oct 1998 22:58:51 -0400 (EDT) Original-Received: (from gnus@localhost) by ljz.asfast.net (8.8.7/8.8.7) id WAA10438; Tue, 20 Oct 1998 22:58:47 -0400 Original-To: ding@gnus.org Original-Cc: larsi@gnus.org X-Face: "!ga1s|?LNLE3MeeeEYs(%LIl9q[xV9!j4#xf4!**BFW_ihlOb;:Slb>)vy>CJM 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