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: Thu, 4 Jan 2018 15:51:11 +0000 Message-ID: <20180104155111.GB6846@ACM> References: <20180103124543.GA5435@ACM> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: blaine.gmane.org 1515081234 20822 195.159.176.226 (4 Jan 2018 15:53:54 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Thu, 4 Jan 2018 15:53:54 +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 Thu Jan 04 16:53:49 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 1eX7px-0004sY-OP for ged-emacs-devel@m.gmane.org; Thu, 04 Jan 2018 16:53:45 +0100 Original-Received: from localhost ([::1]:46033 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1eX7rw-0004vd-Uz for ged-emacs-devel@m.gmane.org; Thu, 04 Jan 2018 10:55:49 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:50047) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1eX7re-0004qw-Rt for emacs-devel@gnu.org; Thu, 04 Jan 2018 10:55:40 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1eX7rX-00085r-QX for emacs-devel@gnu.org; Thu, 04 Jan 2018 10:55:30 -0500 Original-Received: from colin.muc.de ([193.149.48.1]:64497 helo=mail.muc.de) by eggs.gnu.org with smtp (Exim 4.71) (envelope-from ) id 1eX7rX-0007xj-1F for emacs-devel@gnu.org; Thu, 04 Jan 2018 10:55:23 -0500 Original-Received: (qmail 54530 invoked by uid 3782); 4 Jan 2018 15:55:18 -0000 Original-Received: from acm.muc.de (p548C72B8.dip0.t-ipconnect.de [84.140.114.184]) by colin.muc.de (tmda-ofmipd) with ESMTP; Thu, 04 Jan 2018 16:55:17 +0100 Original-Received: (qmail 8353 invoked by uid 1000); 4 Jan 2018 15:51:11 -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:221595 Archived-At: Hello, Stefan. On Wed, Jan 03, 2018 at 16:51:29 -0500, Stefan Monnier wrote: > > 6. Write and run a script which executes each of these primitives whilst > > counting the number of times it invokes before-change-hooks and > > after-change-hooks. > FWIW, we do not try to make those numbers match (and their begin/end > specs don't necessarily match either). In practice, these numbers match for the vast majority of buffer changing calls, and they match at 1-1. They match for all the "primitive" primitives, which are basically insert, delete, and possibly change. These numbers, in an ideal world, would match. It is only because we have "non-primitive" primitives (i.e. primitives which perform several distinct buffer changes) that they don't. > What we aim to do (i.e. what defines what I would consider as a bug) is > to make sure every a-c-f is preceded by a "covering" b-c-f. IOW, b-c-f > may be followed by any number of a-f-c (including 0) as long as those > are within the text chunk covered by the b-f-c. Yes. That applies, however, only to "compound primitives", not to the "primitive primitives", insert and delete, which comprise nearly all the calls in actual use, which are all 1-1. It is an awkward state of affairs, where after-c-f's have somehow got to "remember" that they may only be processing part of the change announced by before-c-f. It is also not true: insert-file-contents, in circumstances explored in summer 2016, invokes only a-c-f, not b-c-f. > Some of your results clearly indicate what I'd consider as bugs. > E.g. `erase-buffer` should call those hooks (unless the buffer was > already empty). I've had a look at the source, and erase-buffer clearly calls the two hooks. I can't at the moment see what went wrong. > OTOH for upcase-region 1 call to b-c-f and 0 to a-c-f is acceptable. I don't really agree, but that won't change anything. ;-( > For most of the others, a deeper inspection would be needed to figure > out if there's an actual bug or if it's just a normal occurrence. We know there is a bug in insert-file-contents (See summer 2016). I would be surprised indeed if there weren't others, too. A way to fix them if we were going to (which we're not), would be to take all the b-c-f and a-c-f calls out of the "compound primitives" and have the latter effect their actions through calling the "true primitivies". However, we could improve the documentation of this situation in the eilsp manual. > Stefan -- Alan Mackenzie (Nuremberg, Germany).