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 13:16:23 -0500 Message-ID: References: <20180103124543.GA5435@ACM> <20180104155111.GB6846@ACM> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: blaine.gmane.org 1515089837 27984 195.159.176.226 (4 Jan 2018 18:17:17 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Thu, 4 Jan 2018 18:17:17 +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 19:17:13 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 1eXA4l-0006wg-4y for ged-emacs-devel@m.gmane.org; Thu, 04 Jan 2018 19:17:11 +0100 Original-Received: from localhost ([::1]:58201 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1eXA6k-0001wh-7c for ged-emacs-devel@m.gmane.org; Thu, 04 Jan 2018 13:19:14 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:44316) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1eXA44-0007U6-PE for emacs-devel@gnu.org; Thu, 04 Jan 2018 13:16:29 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1eXA41-0000bZ-BI for emacs-devel@gnu.org; Thu, 04 Jan 2018 13:16:28 -0500 Original-Received: from pmta31.teksavvy.com ([76.10.157.38]:50628) by eggs.gnu.org with esmtps (TLS1.0:RSA_ARCFOUR_SHA1:16) (Exim 4.71) (envelope-from ) id 1eXA41-0000Zu-38 for emacs-devel@gnu.org; Thu, 04 Jan 2018 13:16:25 -0500 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A2FVLQDAbk5a/xCds2tcg0AvgVqJSYYHj?= =?us-ascii?q?hQBggAzAZkLhT8EAgKEM0UTAQEBAQEBAQEBA2gohSUBBAFWDxQFCwsOJhIUGA0?= =?us-ascii?q?kijkItDSKPgEBAQcCJoQThVGDLosaBZM3hjOJbKFGh3qTYYRrNyKBTzIaCDCCa?= =?us-ascii?q?IR0I4lKAQEB?= X-IPAS-Result: =?us-ascii?q?A2FVLQDAbk5a/xCds2tcg0AvgVqJSYYHjhQBggAzAZkLhT8?= =?us-ascii?q?EAgKEM0UTAQEBAQEBAQEBA2gohSUBBAFWDxQFCwsOJhIUGA0kijkItDSKPgEBA?= =?us-ascii?q?QcCJoQThVGDLosaBZM3hjOJbKFGh3qTYYRrNyKBTzIaCDCCaIR0I4lKAQEB?= X-IronPort-AV: E=Sophos;i="5.46,315,1511845200"; d="scan'208";a="16781652" 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 13:16:24 -0500 Original-Received: by pastel.home (Postfix, from userid 20848) id E89A96084B; Thu, 4 Jan 2018 13:16:23 -0500 (EST) In-Reply-To: <20180104155111.GB6846@ACM> (Alan Mackenzie's message of "Thu, 4 Jan 2018 15:51:11 +0000") X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 76.10.157.38 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:221598 Archived-At: >> 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. Yes, as discussed numerous times in the past ;-) > These numbers, in an ideal world, would match. Not in my ideal world, no. > It is also not true: As mentioned, I'd consider that as a bug. > insert-file-contents, in circumstances explored in > summer 2016, invokes only a-c-f, not b-c-f. And indeed, I considered it a bug and AFAIK this is now fixed. >> 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). ^^ was > I would be surprised indeed if there weren't others, too. I would too. > However, we could improve the documentation of this situation in the > elisp manual. We currently say: Do @emph{not} expect the before-change hooks and the after-change hooks be called in balanced pairs around each buffer change. Also don't expect the before-change hooks to be called for every chunk of text Emacs is about to delete. These hooks are provided on the assumption that Lisp programs will use either before- or the after-change hooks, but not both, and the boundaries of the region where the changes happen might include more than just the actual changed text, or even lump together several changes done piecemeal. 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). Stefan