From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Re: Lisp primitives and their calling of the change hooks Date: Fri, 05 Jan 2018 21:53:25 +0200 Message-ID: <83lghc9j62.fsf@gnu.org> References: <20180103124543.GA5435@ACM> <20180104155111.GB6846@ACM> <20180104211154.GC6846@ACM> <838tdcbxrb.fsf@gnu.org> Reply-To: Eli Zaretskii NNTP-Posting-Host: blaine.gmane.org X-Trace: blaine.gmane.org 1515181955 5179 195.159.176.226 (5 Jan 2018 19:52:35 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Fri, 5 Jan 2018 19:52:35 +0000 (UTC) Cc: acm@muc.de, emacs-devel@gnu.org To: Stefan Monnier Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Fri Jan 05 20:52:30 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 1eXY2W-0000zX-Sz for ged-emacs-devel@m.gmane.org; Fri, 05 Jan 2018 20:52:29 +0100 Original-Received: from localhost ([::1]:55759 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1eXY4W-00036S-6u for ged-emacs-devel@m.gmane.org; Fri, 05 Jan 2018 14:54:32 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:38292) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1eXY3u-000367-1L for emacs-devel@gnu.org; Fri, 05 Jan 2018 14:53:55 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1eXY3q-0000k0-2j for emacs-devel@gnu.org; Fri, 05 Jan 2018 14:53:54 -0500 Original-Received: from fencepost.gnu.org ([2001:4830:134:3::e]:37117) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1eXY3p-0000jn-T2; Fri, 05 Jan 2018 14:53:49 -0500 Original-Received: from [176.228.60.248] (port=1400 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1eXY3o-00014L-OM; Fri, 05 Jan 2018 14:53:49 -0500 In-reply-to: (message from Stefan Monnier on Fri, 05 Jan 2018 11:50:56 -0500) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 2001:4830:134:3::e 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:221629 Archived-At: > From: Stefan Monnier > Cc: Alan Mackenzie , emacs-devel@gnu.org > Date: Fri, 05 Jan 2018 11:50:56 -0500 > > 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". We don't normally include such "preemptive" explanations in the manual. If the text doesn't say one should expect balanced calls, the reader has no reason to expect balanced calls. The current text even makes a point of saying that explicitly. > 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. This basically says the calls are mostly balanced, but don't rely on that, because sometimes they aren't". The text about after-change-functions being called zero or more times adds non-trivial information, but what is its practical usefulness? Same with the text about BEG and END. Maybe I don't understand what are we trying to accomplish with these changes, and that's why I fail to see why the proposed changes are for the better.