From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Stefan Monnier Newsgroups: gmane.emacs.devel Subject: Re: Lisp primitives and their calling of the change hooks Date: Fri, 05 Jan 2018 11:50:56 -0500 Message-ID: References: <20180103124543.GA5435@ACM> <20180104155111.GB6846@ACM> <20180104211154.GC6846@ACM> <838tdcbxrb.fsf@gnu.org> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: blaine.gmane.org 1515170962 9849 195.159.176.226 (5 Jan 2018 16:49:22 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Fri, 5 Jan 2018 16:49:22 +0000 (UTC) User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.0.50 (gnu/linux) Cc: Alan Mackenzie , emacs-devel@gnu.org To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Fri Jan 05 17:49:17 2018 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1eXVB6-0001aE-Hl for ged-emacs-devel@m.gmane.org; Fri, 05 Jan 2018 17:49:08 +0100 Original-Received: from localhost ([::1]:48820 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1eXVD4-0006Gm-5x for ged-emacs-devel@m.gmane.org; Fri, 05 Jan 2018 11:51:10 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:45508) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1eXVCx-0006GQ-NE for emacs-devel@gnu.org; Fri, 05 Jan 2018 11:51:04 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1eXVCw-0006Fs-Rf for emacs-devel@gnu.org; Fri, 05 Jan 2018 11:51:03 -0500 Original-Received: from pmta21.teksavvy.com ([76.10.157.36]:13031) by eggs.gnu.org with esmtps (TLS1.0:RSA_ARCFOUR_SHA1:16) (Exim 4.71) (envelope-from ) id 1eXVCs-0006AT-6H; Fri, 05 Jan 2018 11:50:58 -0500 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A2FzOABqrE9a/yyKSC1dHgEGDIM+gVqDb?= =?us-ascii?q?YVchHqPA4ICmT+FRQKEMUMUAQEBAQEBAQEBA2gohSUBBAFlFAULCw0nEhQYMYo?= =?us-ascii?q?6CLJ6IQKKGwEBAQcCJoQUghWGbYsaBZM4kCSLe5VNKIdSmE82I4FQMhoIMIJoh?= =?us-ascii?q?HQjihIBAQE?= X-IPAS-Result: =?us-ascii?q?A2FzOABqrE9a/yyKSC1dHgEGDIM+gVqDbYVchHqPA4ICmT+?= =?us-ascii?q?FRQKEMUMUAQEBAQEBAQEBA2gohSUBBAFlFAULCw0nEhQYMYo6CLJ6IQKKGwEBA?= =?us-ascii?q?QcCJoQUghWGbYsaBZM4kCSLe5VNKIdSmE82I4FQMhoIMIJohHQjihIBAQE?= X-IronPort-AV: E=Sophos;i="5.46,319,1511845200"; d="scan'208";a="16909534" Original-Received: from unknown (HELO pastel.home) ([45.72.138.44]) by smtp.teksavvy.com with ESMTP; 05 Jan 2018 11:50:56 -0500 Original-Received: by pastel.home (Postfix, from userid 20848) id 5D19765697; Fri, 5 Jan 2018 11:50:56 -0500 (EST) In-Reply-To: <838tdcbxrb.fsf@gnu.org> (Eli Zaretskii's message of "Fri, 05 Jan 2018 08:55:20 +0200") X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 76.10.157.36 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.org gmane.emacs.devel:221623 Archived-At: > How will the reader know to distinguish between these two classes of > primitives? He won't and shouldn't attempt to (the boundary between those two is an internal implementation detail that is subject to change). > Without such an ability, the extra accuracy in this text > is not useful. I find it useful in order to explain why naively observing the behavior may give one the impression that all b-c-f and a-c-f calls are "balanced". Maybe the first paragraph should be reworded a bit so it doesn't sound like a promise of behavior? How 'bout: The vast bulk of buffer changes will call `before-change-functions' and `after-change-functions' in balanced pairs, once for each change where the arguments to these hooks will exactly delimit the change being made. Yet, hook functions should not rely on this being always the case: Other, more complex primitives may call `before-change-functions' once before making changes and then call `after-change-functions' zero, one, or several times, depending on how many individual changes the primitive makes. The `BEG' and `END' arguments to `before-change-functions' will enclose a region in which the individual changes are made, but won't necessarily be the minimal such region. The `BEG', `END', and `OLD-LEN' arguments to each successive call of `after-change-functions' will more accurately delimit the current change. -- Stefan