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: Thu, 04 Jan 2018 16:36:42 -0500 Message-ID: References: <20180103124543.GA5435@ACM> <20180104155111.GB6846@ACM> <20180104211154.GC6846@ACM> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: blaine.gmane.org 1515101695 17870 195.159.176.226 (4 Jan 2018 21:34:55 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Thu, 4 Jan 2018 21:34:55 +0000 (UTC) User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.0.50 (gnu/linux) Cc: emacs-devel@gnu.org To: Alan Mackenzie Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Thu Jan 04 22:34:51 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 1eXDA2-0004KN-OJ for ged-emacs-devel@m.gmane.org; Thu, 04 Jan 2018 22:34:50 +0100 Original-Received: from localhost ([::1]:44598 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1eXDC1-0000PZ-VR for ged-emacs-devel@m.gmane.org; Thu, 04 Jan 2018 16:36:53 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:52282) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1eXDBu-0000OP-3G for emacs-devel@gnu.org; Thu, 04 Jan 2018 16:36:47 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1eXDBr-0004WX-An for emacs-devel@gnu.org; Thu, 04 Jan 2018 16:36:46 -0500 Original-Received: from pmta11.teksavvy.com ([76.10.157.34]:7986) by eggs.gnu.org with esmtps (TLS1.0:RSA_ARCFOUR_SHA1:16) (Exim 4.71) (envelope-from ) id 1eXDBr-0004Vg-4t for emacs-devel@gnu.org; Thu, 04 Jan 2018 16:36:43 -0500 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A2FNFQBgnU5a/xCds2tdg2+BWoNthVyGB?= =?us-ascii?q?44UAYIAMwGZC4U/BAIChDNEFAEBAQEBAQEBAQNoKIUlAQQBVg8UBQsLDiYSFBg?= =?us-ascii?q?NJIo5CLN5ijwBAQEHAiaEE4h/ixoFkzeGM4lsoUaHephMNiOBTzIaCDCCaIR0I?= =?us-ascii?q?4lKAQEB?= X-IPAS-Result: =?us-ascii?q?A2FNFQBgnU5a/xCds2tdg2+BWoNthVyGB44UAYIAMwGZC4U?= =?us-ascii?q?/BAIChDNEFAEBAQEBAQEBAQNoKIUlAQQBVg8UBQsLDiYSFBgNJIo5CLN5ijwBA?= =?us-ascii?q?QEHAiaEE4h/ixoFkzeGM4lsoUaHephMNiOBTzIaCDCCaIR0I4lKAQEB?= X-IronPort-AV: E=Sophos;i="5.46,315,1511845200"; d="scan'208";a="17381717" Original-Received: from 107-179-157-16.cpe.teksavvy.com (HELO pastel.home) ([107.179.157.16]) by smtp.teksavvy.com with ESMTP; 04 Jan 2018 16:36:42 -0500 Original-Received: by pastel.home (Postfix, from userid 20848) id 0D0B2654AD; Thu, 4 Jan 2018 16:36:42 -0500 (EST) In-Reply-To: <20180104211154.GC6846@ACM> (Alan Mackenzie's message of "Thu, 4 Jan 2018 21:11:54 +0000") X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 76.10.157.34 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:221602 Archived-At: >> 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 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. Stefan