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: Fri, 5 Jan 2018 11:41:07 +0000 Message-ID: <20180105114107.GA6954@ACM> 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; charset=us-ascii X-Trace: blaine.gmane.org 1515152625 7090 195.159.176.226 (5 Jan 2018 11:43:45 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Fri, 5 Jan 2018 11:43:45 +0000 (UTC) User-Agent: Mutt/1.7.2 (2016-11-26) Cc: monnier@iro.umontreal.ca, emacs-devel@gnu.org To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Fri Jan 05 12:43:41 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 1eXQPM-00011X-HS for ged-emacs-devel@m.gmane.org; Fri, 05 Jan 2018 12:43:32 +0100 Original-Received: from localhost ([::1]:35469 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1eXQRL-0001Xq-Mf for ged-emacs-devel@m.gmane.org; Fri, 05 Jan 2018 06:45:35 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:45372) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1eXQRE-0001WO-HI for emacs-devel@gnu.org; Fri, 05 Jan 2018 06:45:29 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1eXQRB-00011q-6a for emacs-devel@gnu.org; Fri, 05 Jan 2018 06:45:28 -0500 Original-Received: from colin.muc.de ([193.149.48.1]:58251 helo=mail.muc.de) by eggs.gnu.org with smtp (Exim 4.71) (envelope-from ) id 1eXQRA-0000zP-HU for emacs-devel@gnu.org; Fri, 05 Jan 2018 06:45:24 -0500 Original-Received: (qmail 26216 invoked by uid 3782); 5 Jan 2018 11:45:22 -0000 Original-Received: from acm.muc.de (p548C703C.dip0.t-ipconnect.de [84.140.112.60]) by colin.muc.de (tmda-ofmipd) with ESMTP; Fri, 05 Jan 2018 12:45:21 +0100 Original-Received: (qmail 7340 invoked by uid 1000); 5 Jan 2018 11:41:07 -0000 Content-Disposition: inline In-Reply-To: <838tdcbxrb.fsf@gnu.org> 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:221611 Archived-At: Hello, Eli. On Fri, Jan 05, 2018 at 08:55:20 +0200, Eli Zaretskii wrote: > > Date: Thu, 4 Jan 2018 21:11:54 +0000 > > From: Alan Mackenzie > > Cc: emacs-devel@gnu.org > > 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. > How will the reader know to distinguish between these two classes of > primitives? Without such an ability, the extra accuracy in this text > is not useful. A good point. Wherein lies the difference, from a programmers point of view? Briefly I think that we have a "complex primitive" when we don't have an exact match between one b-c-f and one a-c-f. How about adding the following paragraph to what comes above: The "complex primitive" case can be distinguised from the "atomic primitive" case because either the call to `after-change-functions' is missing (i.e. there are two consecutive calls to `before-change-functions'), or in the first call to `after-change-functions', `OLD-LEN' is less then `END' - `BEG' in `before-change-functions'. The above leaves unsaid what happens when a "complex primitive" happens to call b-c-f and a-c-f as though it were an "atomic primitive". This doesn't seem important enough to take up the space. Personally, I think that when we come to rationalise and refactor insdel.c and related files sometime in the medium future, we should arrange to have b-c-f and a-c-f called only as "atomic" changes. There is no longer any need to optimise the calling of these hooks, and the irregularites of these optimisations imposes an overhead on the use of these hooks. -- Alan Mackenzie (Nuremberg, Germany).