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, 11 Jan 2018 18:42:00 -0500 Message-ID: References: <20180110184521.GB6175@ACM> <20180110194839.GC6175@ACM> <20180110210334.GD6175@ACM> <20180111173904.GA5453@ACM> <20180111194622.GB5453@ACM> <20180111212029.GC5453@ACM> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: blaine.gmane.org 1515714068 16506 195.159.176.226 (11 Jan 2018 23:41:08 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Thu, 11 Jan 2018 23:41:08 +0000 (UTC) User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.0.50 (gnu/linux) To: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Fri Jan 12 00:41:03 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 1eZmSv-0003a8-5t for ged-emacs-devel@m.gmane.org; Fri, 12 Jan 2018 00:40:57 +0100 Original-Received: from localhost ([::1]:52922 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1eZmUu-0007lP-Rh for ged-emacs-devel@m.gmane.org; Thu, 11 Jan 2018 18:43:00 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:44010) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1eZmUI-0007l2-Vb for emacs-devel@gnu.org; Thu, 11 Jan 2018 18:42:23 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1eZmUF-0004O6-3P for emacs-devel@gnu.org; Thu, 11 Jan 2018 18:42:23 -0500 Original-Received: from [195.159.176.226] (port=36048 helo=blaine.gmane.org) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1eZmUE-0004NJ-S4 for emacs-devel@gnu.org; Thu, 11 Jan 2018 18:42:19 -0500 Original-Received: from list by blaine.gmane.org with local (Exim 4.84_2) (envelope-from ) id 1eZmSA-0000R1-QJ for emacs-devel@gnu.org; Fri, 12 Jan 2018 00:40:10 +0100 X-Injected-Via-Gmane: http://gmane.org/ Original-Lines: 52 Original-X-Complaints-To: usenet@blaine.gmane.org Cancel-Lock: sha1:QXJfRaLJoT9EVoXq2ZZBKQG0Zsg= X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] [fuzzy] X-Received-From: 195.159.176.226 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:221865 Archived-At: >> Implementation flexibility, of course (which apparently Eli doesn't >> want to take advantage of very much). > What flexibility? "Implementation flexibility" here means flexibility in implementing primitives. E.g. not needing to care about "what happens if I get an error after I called b-c-f but before I actually modify the buffer"? >> > and in what conditions would those advantages outweigh the known >> > disadvantages in allowing unbalanced change hooks? >> What known disadvantages? > That b-c-f and a-c-f can't work smoothly together in partnership. They can still work smoothly in partnership. The assumptions and guarantees needed are slightly different but I still haven't seen any example where the difference leads to a more complex implementation of the b-c-f and a-c-f hooks. > Instead, at the moment, to be rigorous, code must use non-nice artifices > to cope with the rare occurences of unbalanced change hook calls. You > know CC Mode does this. An example, in C++ Mode, is where the b-c-f > function removes balanced paren syntax-table text properties from > template delimiters when half of a pair is about to be deleted. This > mechanism expects a matching a-c-f so as to put them back where needed. Yes, cc-mode has trouble because it was designed based on balanced behavior. If you had designed it based on correct assumptions you wouldn't have removed the properties in the before part. You'd instead have made this removal lazily (i.e. in b-c-f just collect the info from the about-to-be modified region (could be as simple as stashing (buffer-substring beg end) or some buffer position indicating which template delimiters will need to be re-analyzed), and then use it in the a-c-f). I don't see any reason why the resulting system would be noticeably more complex or less efficient. Going from one to the other is extra work, but that's not the fault of the system. > Indeed, rigorous pairing of b-c-f and a-c-f would increase the > flexibility of programs using them, not decrease it. Yes, by definition. But I still haven't seen any example where the difference actually matters. Stefan