From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.io/gmane.emacs.gnus.general/18007 Path: main.gmane.org!not-for-mail From: Lloyd Zusman Newsgroups: gmane.emacs.gnus.general Subject: Re: I fixed it, but I need Lars ... (Was: *Group* buffer disappearance) Date: 21 Oct 1998 09:54:58 -400 Sender: owner-ding@hpc.uh.edu Message-ID: References: NNTP-Posting-Host: coloc-standby.netfonds.no X-Trace: main.gmane.org 1035156607 3882 80.91.224.250 (20 Oct 2002 23:30:07 GMT) X-Complaints-To: usenet@main.gmane.org NNTP-Posting-Date: Sun, 20 Oct 2002 23:30:07 +0000 (UTC) Cc: Hrvoje Niksic 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 JAA22931 for ; Wed, 21 Oct 1998 09:56: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 IAB16302; Wed, 21 Oct 1998 08:55:42 -0500 (CDT) Original-Received: by sina.hpc.uh.edu (TLB v0.09a (1.20 tibbs 1996/10/09 22:03:07)); Wed, 21 Oct 1998 08:55:28 -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 IAA23333 for ; Wed, 21 Oct 1998 08:55:19 -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 JAA22899 for ; Wed, 21 Oct 1998 09:55:04 -0400 (EDT) Original-Received: (from gnus@localhost) by ljz.asfast.net (8.8.7/8.8.7) id JAA13639; Wed, 21 Oct 1998 09:54:59 -0400 Original-To: ding@gnus.org X-Face: "!ga1s|?LNLE3MeeeEYs(%LIl9q[xV9!j4#xf4!**BFW_ihlOb;:Slb>)vy>CJM writes: > Lloyd Zusman writes: > > > 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'). > > Killing `cur' doesn't look right. The buffer you really want to kill > is the "*mm*" buffer, not the current buffer before that. Yes. This seems correct, and it works under my test scenario. > [ ... correct patch that appears elsewhere snipped ... ] > I used `unwind-protect' so that if a signal occurs during the method, > the undisplayer still gets set. > > (What I don't understand is why the undisplayer method still doesn't > get *called* when I press C-g.) `unwind-protect' alone doesn't trap `C-g' signals. I believe that you have to make use of `condition-case' if you want to trap `C-g'. I have to run to a meeting in a few minutes. When I come back, I'll redo your patch using `condition-case' and post it here. > > 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? > > Yes. The *mm* buffer is temporary stuff used for decoding MIME. We > don't want buffers with random binary contents to stick around, I > think. But by storing the name of the ` *mm*' buffer in the data structure managed by `mm-handle-set-undisplayer', we're assuring that this ` *mm*' buffer gets deleted later. Prior to this, should the buffer get killed within the `mailcap-save-binary-file' method? Would this somehow cause problems later? -- Lloyd Zusman ljz@asfast.com