From mboxrd@z Thu Jan  1 00:00:00 1970
X-Msuck: nntp://news.gmane.io/gmane.emacs.gnus.general/18015
Path: main.gmane.org!not-for-mail
From: Lloyd Zusman <ljz@asfast.com>
Newsgroups: gmane.emacs.gnus.general
Subject: Re: I fixed it, but I need Lars ... (Was: *Group* buffer disappearance)
Date: 21 Oct 1998 11:17:49 -400
Sender: owner-ding@hpc.uh.edu
Message-ID: <ltyaqakkpu.fsf@asfast.com>
References: <m33e8jozss.fsf@sparky.gnus.org> <lt7lxvowyb.fsf@asfast.com> <ltvhleipso.fsf_-_@asfast.com> <kig67degkbb.fsf@jagor.srce.hr> <ltpvbmnhot.fsf@asfast.com> <kigsogif0zi.fsf@jagor.srce.hr> <ltbtn6ars7.fsf@asfast.com> <kighfwyezao.fsf@jagor.srce.hr> <lt3e8ilzrc.fsf@asfast.com> <kigaf2qeyse.fsf@jagor.srce.hr>
NNTP-Posting-Host: coloc-standby.netfonds.no
X-Trace: main.gmane.org 1035156614 3937 80.91.224.250 (20 Oct 2002 23:30:14 GMT)
X-Complaints-To: usenet@main.gmane.org
NNTP-Posting-Date: Sun, 20 Oct 2002 23:30:14 +0000 (UTC)
Cc: Hrvoje Niksic <hniksic@srce.hr>
Return-Path: <owner-ding@hpc.uh.edu>
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 LAA24733
	for <jason@mailhost.sclp.com>; Wed, 21 Oct 1998 11:23:41 -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 KAB17181;
	Wed, 21 Oct 1998 10:18:28 -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 10:18: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 KAA25117 for <ding@hpc.uh.edu>; Wed, 21 Oct 1998 10:18:14 -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 LAA24650
	for <ding@gnus.org>; Wed, 21 Oct 1998 11:17:55 -0400 (EDT)
Original-Received: (from gnus@localhost)
	by ljz.asfast.net (8.8.7/8.8.7) id LAA14149;
	Wed, 21 Oct 1998 11:17:49 -0400
Original-To: ding@gnus.org
X-Face: "!ga1s|?LNLE3MeeeEYs(%LIl9q[xV9!<nimJxd1qyQRquvu5XTnZ:_5VE-G&4*
        EAuW"7oJLIXj'DWrJ0z@,FlwvD2PA@qhQ2R#zgsc14Klk;OSE'*;+l8p?0^nK7*
        X#0zg5wd^!M^2pg,M4Qd^{1viG;fa{}b.s[?g(x$45c]]=@'ZQ&]sPXl!u:hxBA
        v>j4#xf4!**BFW_ihlOb;:Slb>)vy>CJM<qjGM,/6C6\|{))YWm6}Q#?3om%n8
In-Reply-To: Hrvoje Niksic's message of "21 Oct 1998 17:10:25 +0200"
Original-Lines: 27
User-Agent: Gnus/5.070036 (Pterodactyl Gnus v0.36) XEmacs/20.4 (Emerald)
Precedence: list
X-Majordomo: 1.94.jlt7
Xref: main.gmane.org gmane.emacs.gnus.general:18015
X-Report-Spam: http://spam.gmane.org/gmane.emacs.gnus.general:18015

Hrvoje Niksic <hniksic@srce.hr> writes:

> [ ... ]
>
> C-g trap is not undesirable; it's just that you're confusing
> condition-case and unwind-protect.
> 
> condition-case should be used when you want to selectively trap errors
> and do cleanup code.  What we need here is the cleanup code that
> evaluates no matter what way we exit from the function -- including
> C-g.  This is exactly what unwind-protect is for.
>
> So, my patch adds unwind protection twice: once for the undisplayer to
> be set, and once for the buffer to be killed after it is saved (or
> not).  I hope this makes sense.

It's clear to me now.  I had thought that the only time we would want
to clean up prior to `gnus-summary-exit' is if an error or an abort
occurred during the method call.  If we're supposed to be cleaning up
prior to `gnus-summary-exit' even in the case where the method
succeeds, then I understand why you're proceeding as you are.

... or at least I *think* I understand. :)

-- 
 Lloyd Zusman
 ljz@asfast.com