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: Sun, 7 Jan 2018 17:54:18 +0000 Message-ID: <20180107175418.GD22254@ACM> References: <20180104211154.GC6846@ACM> <20180106151839.GB23284@ACM> <20180106202403.GD23284@ACM> <20180107113628.GA22254@ACM> <83o9m599du.fsf@gnu.org> <20180107120859.GB22254@ACM> <20180107135629.GC22254@ACM> <83mv1p8vki.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 1515347869 27663 195.159.176.226 (7 Jan 2018 17:57:49 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Sun, 7 Jan 2018 17:57:49 +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 Sun Jan 07 18:57:44 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 1eYFCW-0006hS-GI for ged-emacs-devel@m.gmane.org; Sun, 07 Jan 2018 18:57:40 +0100 Original-Received: from localhost ([::1]:60949 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1eYFEV-0003Pc-UP for ged-emacs-devel@m.gmane.org; Sun, 07 Jan 2018 12:59:43 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:37891) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1eYFDg-0003O9-RJ for emacs-devel@gnu.org; Sun, 07 Jan 2018 12:58:53 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1eYFDd-0004nd-PM for emacs-devel@gnu.org; Sun, 07 Jan 2018 12:58:52 -0500 Original-Received: from colin.muc.de ([193.149.48.1]:53806 helo=mail.muc.de) by eggs.gnu.org with smtp (Exim 4.71) (envelope-from ) id 1eYFDd-0004ma-D4 for emacs-devel@gnu.org; Sun, 07 Jan 2018 12:58:49 -0500 Original-Received: (qmail 93525 invoked by uid 3782); 7 Jan 2018 17:58:48 -0000 Original-Received: from acm.muc.de (p548C75D0.dip0.t-ipconnect.de [84.140.117.208]) by colin.muc.de (tmda-ofmipd) with ESMTP; Sun, 07 Jan 2018 18:58:47 +0100 Original-Received: (qmail 14735 invoked by uid 1000); 7 Jan 2018 17:54:18 -0000 Content-Disposition: inline In-Reply-To: <83mv1p8vki.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:221683 Archived-At: Hello, Eli. On Sun, Jan 07, 2018 at 18:47:41 +0200, Eli Zaretskii wrote: > > Date: Sun, 7 Jan 2018 13:56:29 +0000 > > From: Alan Mackenzie > > Cc: monnier@iro.umontreal.ca, emacs-devel@gnu.org > > > > zlib-decompress-region calls del_range, which calls the hooks. Or am > > > > I missing something? > > > Yes, you're right, sorry. There are change-hook calls for the second, > > > deletion, part of the operation. No hooks are called for the first > > > part, the insertion of the decompressed text into the buffer. So > > > zlib-decompress-region is still not right. > > > I'm going to take a careful look for any more such primitives, which > > > have one balanced pair of change hook calls, yet these calls only cover > > > part of the operation. > > There appear to be no more such primitives. > > Should I try to fix zlib-decompress-region? > How do you want to fix it? That function inserts the decompressed > stuff, then deletes the original compressed stuff. What do you want > that to produce in terms of the change hooks? IIUC, zlib-decompress-region decompresses in chunks into the gap, expanding the gap after each chunk. The strategy of one overarching before-change-functions followed by lots of little after-change-functions can't really work here, since we don't know in advance how big the region being written to is. In fact, I think this strategy is used only when the individual changes don't change the buffer's size, e.g. when doing upcase-region, or translate-region-internal. We don't have this here. One way of doing it would be to have a balanced pair of b/a-c-f for each chunk of text inserted. The other way would be having a single b/a-c-f pair. For reasons I can't articulate, I think the single pair of hooks would be better; less "noisy", perhaps. But either strategy would work well. -- Alan Mackenzie (Nuremberg, Germany).