From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Chong Yidong Newsgroups: gmane.emacs.devel Subject: Re: Please try Pmail Date: Wed, 21 Jan 2009 10:06:52 -0500 Message-ID: <87zlhkitpv.fsf@cyd.mit.edu> References: <87r6303c31.fsf@cyd.mit.edu> <87ljt83svc.fsf@cyd.mit.edu> <87eiyyvz2h.fsf@cyd.mit.edu> <873afdti10.fsf@cyd.mit.edu> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: ger.gmane.org 1232550469 10773 80.91.229.12 (21 Jan 2009 15:07:49 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 21 Jan 2009 15:07:49 +0000 (UTC) Cc: rms@gnu.org, emacs-devel@gnu.org To: "Stefan Monnier" Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Wed Jan 21 16:09:00 2009 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by lo.gmane.org with esmtp (Exim 4.50) id 1LPegP-0005W4-Fx for ged-emacs-devel@m.gmane.org; Wed, 21 Jan 2009 16:07:57 +0100 Original-Received: from localhost ([127.0.0.1]:54647 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1LPef8-00035f-Ak for ged-emacs-devel@m.gmane.org; Wed, 21 Jan 2009 10:06:38 -0500 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1LPef3-00035L-IZ for emacs-devel@gnu.org; Wed, 21 Jan 2009 10:06:33 -0500 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1LPef2-00033n-37 for emacs-devel@gnu.org; Wed, 21 Jan 2009 10:06:33 -0500 Original-Received: from [199.232.76.173] (port=54567 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1LPef2-00033g-0k for emacs-devel@gnu.org; Wed, 21 Jan 2009 10:06:32 -0500 Original-Received: from cyd.mit.edu ([18.115.2.24]:42674) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1LPeey-0007ty-V0; Wed, 21 Jan 2009 10:06:29 -0500 Original-Received: by cyd.mit.edu (Postfix, from userid 1000) id C44CC57E222; Wed, 21 Jan 2009 10:06:52 -0500 (EST) In-Reply-To: (Stefan Monnier's message of "Tue, 20 Jan 2009 23:18:10 -0500") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.0.60 (gnu/linux) X-detected-operating-system: by monty-python.gnu.org: Genre and OS details not recognized. X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:108041 Archived-At: "Stefan Monnier" writes: >> The annotation functions would need to add functions to that hook when >> they are run. > > Not really. When they switch to another buffer, they may need to adjust > that hook in that buffer. The default value could be `kill-buffer', so > as to preserve current behavior. > >> Another idea: allow a new type of return value for annotation functions, >> and use this to keep track of buffers to be killed. For example, allow >> annotation functions to return (FUN1 . FUN2), where FUN1 and FUN2 are >> lambda functions. Then FUN1 is called during annotation, and FUN2 is >> called after other annotations have taken place. > > Since they return a buffer already, we may as well store the FUN2 > inside that buffer (as a buffer-local var). They don't return a buffer. They switch to a different buffer, and return nil. Here's one reason against adding a new hook to post-process annotations: to do this particular job right, we need to run all the hook functions in all the buffers that have been swapped to (so as to pick up their local values). This violates the usual behavior of run-hooks, which only runs the buffer-local value of the hook, followed by the global value of the hook. The lambda function idea tries to avoid this by making the post-processing part of the annotations process.