From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Alan Mackenzie Newsgroups: gmane.emacs.devel Subject: Re: (insert ?\n) spuriously calls before-change-functions twice. Help! Date: Tue, 5 Jan 2010 17:31:58 +0000 Message-ID: <20100105173158.GB2639@muc.de> References: <20100105110954.GA2639@muc.de> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: ger.gmane.org 1262712780 32588 80.91.229.12 (5 Jan 2010 17:33:00 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 5 Jan 2010 17:33:00 +0000 (UTC) Cc: emacs-devel@gnu.org To: Stefan Monnier Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Jan 05 18:32:52 2010 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 1NSDH0-0001Us-Ld for ged-emacs-devel@m.gmane.org; Tue, 05 Jan 2010 18:32:50 +0100 Original-Received: from localhost ([127.0.0.1]:40013 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1NSDH1-0000Vs-5g for ged-emacs-devel@m.gmane.org; Tue, 05 Jan 2010 12:32:51 -0500 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1NSDGl-0000Ro-Vu for emacs-devel@gnu.org; Tue, 05 Jan 2010 12:32:36 -0500 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1NSDGh-0000Pp-65 for emacs-devel@gnu.org; Tue, 05 Jan 2010 12:32:35 -0500 Original-Received: from [199.232.76.173] (port=46785 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1NSDGg-0000Pf-RS for emacs-devel@gnu.org; Tue, 05 Jan 2010 12:32:30 -0500 Original-Received: from colin.muc.de ([193.149.48.1]:3282 helo=mail.muc.de) by monty-python.gnu.org with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1NSDGg-0008Te-3T for emacs-devel@gnu.org; Tue, 05 Jan 2010 12:32:30 -0500 Original-Received: (qmail 14991 invoked by uid 3782); 5 Jan 2010 17:25:44 -0000 Original-Received: from acm.muc.de (pD9E506C5.dip.t-dialin.net [217.229.6.197]) by colin2.muc.de (tmda-ofmipd) with ESMTP; Tue, 05 Jan 2010 18:25:42 +0100 Original-Received: (qmail 8485 invoked by uid 1000); 5 Jan 2010 17:31:58 -0000 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.9i X-Delivery-Agent: TMDA/1.1.5 (Fettercairn) X-Primary-Address: acm@muc.de X-detected-operating-system: by monty-python.gnu.org: FreeBSD 4.6-4.9 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:119452 Archived-At: Hi, Stefan, On Tue, Jan 05, 2010 at 10:22:26AM -0500, Stefan Monnier wrote: > > In emacs -Q, in an AWK buffer, do M-: (insert ?\n). The following > [...] > > However, M-: (insert "\n") just does the Right Thing. > That's curious indeed. > > This second invocation of before-change-functions is surely a bug. I > > can make this happen in a Fundamental Mode buffer in my normal Emacs > > session, but not in Emacs -Q. > Can you try to figure out which diference between "emacs -Q" and your > "normal Emacs session" triggers the problem? I think I've tracked down what's happening. After inserting the ?\n (any other character is just the same), Emacs clears any text properties from the new character by calling set_properties. This, in its turn, invokes before-change-functions. A more detailed call stack is: Finsert calls general_insert_function (insert, insert_from_string, 0, nargs, args) calls (*insert_func) (str, len), namely insert (str, len), calls insert_1_both (string, len, nbytes, 0, 1, 0), calls prepare_to_modify_buffer, calls signal_before_change. This does the first invocation of b_c_f. <====== insert_1_both inserts the character ?\n into the buffer. insert_1_both (conditionally on BUF_INTERVALS) calls set_text_properties on the newly inserted character, calls modify_region, calls prepare_to_modify_buffer, calls signal_before_change. This does the second invocation of b_c_f. <============================= There doesn't seem to be any system in where the two change hooks are invoked. For example, insert directly calls signal_after_change, yet not signal_before_change; surely invocations of these should be paired. I think there needs to be two levels of these primitive: a "user level", which invokes the change hooks, and calls the "internal level" to do the actual work. Other primitives would call only the "internal level". Or something like that. For CC Mode, I will put in a test for two consecutive invocations of before-change-functions without an after-change-functions between them. In such a case, I then ignore the second invocation. I think. > Stefan -- Alan Mackenzie (Nuremberg, Germany).