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, 11 Jan 2018 21:20:29 +0000 Message-ID: <20180111212029.GC5453@ACM> References: <20180110184521.GB6175@ACM> <20180110194839.GC6175@ACM> <20180110210334.GD6175@ACM> <20180111173904.GA5453@ACM> <20180111194622.GB5453@ACM> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: blaine.gmane.org 1515706240 8323 195.159.176.226 (11 Jan 2018 21:30:40 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Thu, 11 Jan 2018 21:30:40 +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 11 22:30:36 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 1eZkQU-0000Oy-2W for ged-emacs-devel@m.gmane.org; Thu, 11 Jan 2018 22:30:18 +0100 Original-Received: from localhost ([::1]:44425 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1eZkSO-0002SR-Cu for ged-emacs-devel@m.gmane.org; Thu, 11 Jan 2018 16:32:16 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:45432) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1eZkME-00064p-2U for emacs-devel@gnu.org; Thu, 11 Jan 2018 16:25:55 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1eZkMA-0002MK-Ps for emacs-devel@gnu.org; Thu, 11 Jan 2018 16:25:54 -0500 Original-Received: from colin.muc.de ([193.149.48.1]:46440 helo=mail.muc.de) by eggs.gnu.org with smtp (Exim 4.71) (envelope-from ) id 1eZkMA-0002Ir-IQ for emacs-devel@gnu.org; Thu, 11 Jan 2018 16:25:50 -0500 Original-Received: (qmail 59501 invoked by uid 3782); 11 Jan 2018 21:25:46 -0000 Original-Received: from acm.muc.de (p548C73AF.dip0.t-ipconnect.de [84.140.115.175]) by colin.muc.de (tmda-ofmipd) with ESMTP; Thu, 11 Jan 2018 22:25:46 +0100 Original-Received: (qmail 7194 invoked by uid 1000); 11 Jan 2018 21:20:29 -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:221859 Archived-At: Hello, Stefan. On Thu, Jan 11, 2018 at 15:15:49 -0500, Stefan Monnier wrote: > >> >> I'm very far from convinced about the "elaborate special handling". > >> > Well, you agree that there're no advantages to having unbalanced change > >> > hooks, > >> No I don't. > > You don't? > How can you be surprised? Not surprised. I've just spent the last three posts, and quite a few before that, trying to get you to tell me in detail what's desirable about unbalanced change hooks. I'd genuinely like to know, since I couldn't (and still can't) see this. [ .... ] > > What, then, might those advantages be, > Implementation flexibility, of course (which apparently Eli doesn't > want to take advantage of very much). What flexibility? What can you do with unbalanced hooks that you can't do when you constrain yourself to balance them? Are you talking about flexibility in writing primitives or in using them? Can you give me an example? > > 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. 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. Indeed, rigorous pairing of b-c-f and a-c-f would increase the flexibility of programs using them, not decrease it. > Stefan -- Alan Mackenzie (Nuremberg, Germany).