Path: utzoo!utgpu!watmath!att!bellcore!rutgers!mailrus!uflorida!novavax!weiner
From: weiner@novavax.UUCP (Bob Weiner)
Newsgroups: comp.emacs
Subject: Re: Problem with buffer object life in GNU Emacs Lisp
Message-ID: <1421@novavax.UUCP>
Date: 8 Aug 89 04:38:05 GMT
References: <1414@novavax.UUCP> <1989Aug7.152011.10962@talos.uucp>
Organization: Nova University, Fort Lauderdale, FL
Lines: 27
In-reply-to: kjones@talos.uucp's message of 7 Aug 89 15:20:11 GMT
Posting-Front-End: GNU Emacs 18.47.5 of Tue Sep 15 1987 on novavax (berkeley-unix)

In article <1989Aug7.152011.10962@talos.uucp> kjones@talos.uucp (Kyle Jones) writes:

   Bob Weiner writes:
    > If you do something like:
    > 
    > (setq rmail-summary-buffer (get-buffer "RMAIL-summary"))
    > 
    > and then kill the actual summary buffer, rmail-summary-buffer will now
    > reference a 'killed buffer' object.  Typical code uses get-buffer to
    > check if such a buffer exists, if it does not, get-buffer usually returns
    > nil.  The global reference rmail-summary-buffer prevents the object from
    > being garbage collected so (get-buffer "RMAIL-summary") still returns a
    > non-nil value and your conditional code fails.
    > [...]
    > This is all based on GNU Emacs 18.52.  Thanks for any help.

   I tried this under GNU Emacs 18.52 here and get-buffer returned nil.
   Could you have confused get-buffer with bufferp?  The latter will return
   non-nil even if it's argument is a killed buffer.

For this example, I assumed you had started up RMAIL and had done an {h}
to generate the summary buffer, this automatically performs the setq.
Then you kill the summary buffer and do the get-buffer.  I definitely
have this problem with get-buffer not with bufferp.
-- 
Bob Weiner, Motorola, Inc.,   USENET:  ...!gatech!uflorida!novavax!weiner
(407) 738-2087