From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: "Stefan Monnier" Newsgroups: gmane.emacs.devel Subject: Re: Please try Pmail Date: Tue, 20 Jan 2009 21:37:49 -0500 Message-ID: References: <87r6303c31.fsf@cyd.mit.edu> <87ljt83svc.fsf@cyd.mit.edu> <87eiyyvz2h.fsf@cyd.mit.edu> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Trace: ger.gmane.org 1232507551 20158 80.91.229.12 (21 Jan 2009 03:12:31 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 21 Jan 2009 03:12:31 +0000 (UTC) Cc: rms@gnu.org, emacs-devel@gnu.org To: "Chong Yidong" Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Wed Jan 21 04:13:43 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 1LPTX6-0000Gf-AR for ged-emacs-devel@m.gmane.org; Wed, 21 Jan 2009 04:13:36 +0100 Original-Received: from localhost ([127.0.0.1]:43767 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1LPTVo-00046g-OK for ged-emacs-devel@m.gmane.org; Tue, 20 Jan 2009 22:12:16 -0500 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1LPTVj-00046K-HS for emacs-devel@gnu.org; Tue, 20 Jan 2009 22:12:11 -0500 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1LPTVi-000468-1R for emacs-devel@gnu.org; Tue, 20 Jan 2009 22:12:10 -0500 Original-Received: from [199.232.76.173] (port=54491 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1LPTVh-000465-Tt for emacs-devel@gnu.org; Tue, 20 Jan 2009 22:12:09 -0500 Original-Received: from mail.g-wis.com ([204.250.154.18]:3500) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1LPTVg-0000Jp-Ir; Tue, 20 Jan 2009 22:12:08 -0500 thread-index: Acl7cURVor6MiqeDTEW55fJXfjqq9Q== X-Received-From-Address: 69.38.23.210 X-Envelope-From: monnier@iro.umontreal.ca X-Envelope-To: emacs-devel@gnu.org, rms@gnu.org, cyd@stupidchicken.com, monnier@iro.umontreal.ca Original-Received: from ceviche.home ([69.38.23.210]) by mail.g-wis.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 20 Jan 2009 18:37:55 -0800 Original-Received: by ceviche.home (Postfix, from userid 20848) id CF1B8B400C; Tue, 20 Jan 2009 21:37:49 -0500 (EST) Content-Class: urn:content-classes:message Importance: normal Priority: normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.4325 In-Reply-To: <87eiyyvz2h.fsf@cyd.mit.edu> (Chong Yidong's message of "Tue, 20Jan 2009 09:20:38 -0500") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.0.60 (gnu/linux) X-OriginalArrivalTime: 21 Jan 2009 02:37:55.0771 (UTC) FILETIME=[43EA28B0:01C97B71] X-detected-operating-system: by monty-python.gnu.org: Windows 2000 SP4, XP SP1+ X-Greylist: delayed 2049 seconds by postgrey-1.27 at monty-python; Tue, 20 Jan 2009 22:12:07 EST X-Greylist: delayed 2050 seconds by postgrey-1.27 at monty-python; Tue, 20 Jan 2009 22:12:08 EST 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:108022 Archived-At: > /* If build_annotations switched buffers, switch back to BUF. > Kill the temporary buffer that was selected in the meantime. > Since this kill only the last temporary buffer, some buffers remain > not killed if build_annotations switched buffers more than once. > -- K.Handa */ > static Lisp_Object > build_annotations_unwind (buf) > Lisp_Object buf; > { > Lisp_Object tembuf; > if (XBUFFER (buf) == current_buffer) > return Qnil; > tembuf = Fcurrent_buffer (); > Fset_buffer (buf); > Fkill_buffer (tembuf); > return Qnil; > } Duh! I tested saving, and checked that the file's contents was right, but never noticed this. It turns out that this code is used by format-annotate-function, so there's a good reason for it to be there. We should try to find a way to get both cases working right (and even the case where build_annotations switched buffers more than once, ideally). The cleanest solution is to let build_annotations_unwind run some buffer-local hook function (e.g. write-region-post-annotate-function), which can either run kill-buffer, and/or re-narrow the buffer, and/or kill previous buffers. The current code already allows it via kill-buffer-hook, but using that is ugly and will lead to other surprises. Stefan