From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Alan Mackenzie Newsgroups: gmane.emacs.devel Subject: Re: Lisp primitives and their calling of the change hooks Date: Sat, 6 Jan 2018 15:18:39 +0000 Message-ID: <20180106151839.GB23284@ACM> References: <20180103124543.GA5435@ACM> <20180104155111.GB6846@ACM> <20180104211154.GC6846@ACM> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: blaine.gmane.org 1515252086 13282 195.159.176.226 (6 Jan 2018 15:21:26 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Sat, 6 Jan 2018 15:21:26 +0000 (UTC) User-Agent: Mutt/1.7.2 (2016-11-26) Cc: emacs-devel@gnu.org To: Stefan Monnier Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sat Jan 06 16:21:21 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 1eXqHa-0002dE-Fa for ged-emacs-devel@m.gmane.org; Sat, 06 Jan 2018 16:21:14 +0100 Original-Received: from localhost ([::1]:39246 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1eXqJY-00045d-5e for ged-emacs-devel@m.gmane.org; Sat, 06 Jan 2018 10:23:16 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:36600) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1eXqJR-00045K-At for emacs-devel@gnu.org; Sat, 06 Jan 2018 10:23:10 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1eXqJN-0006VG-9X for emacs-devel@gnu.org; Sat, 06 Jan 2018 10:23:09 -0500 Original-Received: from colin.muc.de ([193.149.48.1]:37383 helo=mail.muc.de) by eggs.gnu.org with smtp (Exim 4.71) (envelope-from ) id 1eXqJN-0006Uk-33 for emacs-devel@gnu.org; Sat, 06 Jan 2018 10:23:05 -0500 Original-Received: (qmail 41470 invoked by uid 3782); 6 Jan 2018 15:23:03 -0000 Original-Received: from acm.muc.de (p548C6CC7.dip0.t-ipconnect.de [84.140.108.199]) by colin.muc.de (tmda-ofmipd) with ESMTP; Sat, 06 Jan 2018 16:23:02 +0100 Original-Received: (qmail 7871 invoked by uid 1000); 6 Jan 2018 15:18:39 -0000 Content-Disposition: inline In-Reply-To: X-Delivery-Agent: TMDA/1.1.12 (Macallan) X-Primary-Address: acm@muc.de X-detected-operating-system: by eggs.gnu.org: FreeBSD 9.x [fuzzy] X-Received-From: 193.149.48.1 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:221643 Archived-At: Hello, Stefan. On Thu, Jan 04, 2018 at 16:36:42 -0500, Stefan Monnier wrote: > >> which is lax enough that any behavior could be argued to be acceptable. > >> IOW I think it's too lax. We should probably try and fix it to reflect > >> the fact that every change should be covered by the last preceding b-c-f > >> and should be followed by a corresponding call to a-c-f (and this > >> before the next call to b-c-f). > > Is that quite right? > Probably not quite. > > The upcase-region call in my test had no a-c-f call, almost certainly > > because there were no lower case letters in the buffer at the time. > Indeed, there were no changes, so no need to call a-c-f. > > From your answers in this thread, I'm thinking that every > > primitive-call which could change the buffer will have exactly one > > b-c-f and zero or more a-c-f's. > Sounds about right, tho I expect some primitives might just call insert > and delete a few times, thus calling b-c-f several times. > > How about something like this to replace that paragraph from the elisp > > manual? > > The primitives which atomically insert or delete a contiguous chunk > > of text into or from a buffer will call `before-change-functions' > > and `after-change-functions' in balanced pairs, once for each > > change. The arguments to these hooks will exactly delimit the > > change being made. Calls to these primitives comprise the vast bulk > > of buffer changes. > > Other, more complex primitives aim to call `before-change-functions' > > once before making any changes, then to 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 accurately > > delimit the current change. > Looks good to me, thank you. I've found a discrepancy. Just one. In (transpose-regions 1 10 11 20), the hook calls are, in order, ((1 10) (11 20) (1 20 19)). The two consecutive b-c-f's happen when the two regions are of equal size and non-contiguous. The cause of this is not hard to find: in Ftranspose_region, editfns.c L5204, there are two calls to modify_text on consecutive lines. This seems to be some sort of optimisation. It is not done elsewhere in Ftranspose_region. I dare say this could be fixed easily. > I think in the case of subst-chars-in-region we only call a-c-f one time > (but with tighter bounds than those of the preceding b-c-f) rather than > once per character that's substituted, so maybe "The `BEG', `END', and > `OLD-LEN' arguments to each successive call of `after-change-functions' > will accurately delimit the current change" promises a bit more than we > deliver, although it depends on how we interpret "current change". > In any case, the above is much better than what we have now and I think > it gives a pretty good rendition of our intention. Perhaps for Emacs-27, if we want to fix transpose-regions. > Stefan -- Alan Mackenzie (Nuremberg, Germany).