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 19:48:45 +0000 Message-ID: <20180107194845.GE22254@ACM> References: <20180106202403.GD23284@ACM> <20180107113628.GA22254@ACM> <83o9m599du.fsf@gnu.org> <20180107120859.GB22254@ACM> <20180107135629.GC22254@ACM> <83mv1p8vki.fsf@gnu.org> <83bmi58sao.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 1515354726 727 195.159.176.226 (7 Jan 2018 19:52:06 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Sun, 7 Jan 2018 19:52:06 +0000 (UTC) User-Agent: Mutt/1.7.2 (2016-11-26) Cc: Eli Zaretskii , emacs-devel@gnu.org To: Stefan Monnier Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sun Jan 07 20:52:02 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 1eYGz9-00088k-Hw for ged-emacs-devel@m.gmane.org; Sun, 07 Jan 2018 20:51:59 +0100 Original-Received: from localhost ([::1]:37419 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1eYH19-0006jT-47 for ged-emacs-devel@m.gmane.org; Sun, 07 Jan 2018 14:54:03 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:45831) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1eYH0U-0006jE-2l for emacs-devel@gnu.org; Sun, 07 Jan 2018 14:53:23 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1eYH0R-00039A-18 for emacs-devel@gnu.org; Sun, 07 Jan 2018 14:53:22 -0500 Original-Received: from colin.muc.de ([193.149.48.1]:57467 helo=mail.muc.de) by eggs.gnu.org with smtp (Exim 4.71) (envelope-from ) id 1eYH0Q-00038R-L3 for emacs-devel@gnu.org; Sun, 07 Jan 2018 14:53:18 -0500 Original-Received: (qmail 41278 invoked by uid 3782); 7 Jan 2018 19:53:15 -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 20:53:14 +0100 Original-Received: (qmail 15786 invoked by uid 1000); 7 Jan 2018 19:48:45 -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:221690 Archived-At: Hello, Stefan and Eli. On Sun, Jan 07, 2018 at 14:04:46 -0500, Stefan Monnier wrote: > > I think only the former makes sense, because this function is actually > > a replacement function. > When we perform a "replacement" from Elisp, we do it with insert + > delete-region so there are two calls to each of b-c-f and a-c-f. > So two calls also makes sense. > We could even have one call to at the beginning b-c-f followed by two > calls to a-c-f (one right after inserting the new text and one after > deleting the old text). That would also be acceptable. > And in reality, this choice doesn't really matter (as evidenced by the > fact that noone noticed those calls were missing until now). > We should just pick the one that's easier to implement (and in case we > still a preference because the implementation is just as easy, the > "single calls to b-c-f/a-c-f" is of course the better option). Yes, that's what I've done. Each zlib-decompress-region now has two separate pairs of b/a-c-f, one for insert, then the other for delete. This is the way that other "coding" primitives, like base64-encode-region work. > > Also note that zlib-decompress-region works only in unibyte buffers, > > so in practice almost every caller will immediately call > > decode-coding-region or its ilk, which calls the hooks again. But > > unlike zlib-decompress-region, the decoding stuff will be able to0 > > report character positions, not byte positions. > In practice, I'd also expect both b-c-f and a-c-f to be nil (or > equivalent) when we call zlib-decompress-region. Yes. But it's nice to have things consistent. :-) Anyhow, here's the patch, which appears to work as described above. Any comments? Otherwise I'll commit it. diff --git a/src/decompress.c b/src/decompress.c index 41de6da1dd..07545544aa 100644 --- a/src/decompress.c +++ b/src/decompress.c @@ -141,6 +141,10 @@ This function can be called only in unibyte buffers. */) the same. */ istart = XINT (start); iend = XINT (end); + + /* Do the following before manipulating the gap. */ + modify_text (iend, iend); + move_gap_both (iend, iend); stream.zalloc = Z_NULL; @@ -190,6 +194,8 @@ This function can be called only in unibyte buffers. */) } while (inflate_status == Z_OK); + signal_after_change (iend, 0, unwind_data.nbytes); + if (inflate_status != Z_STREAM_END) return unbind_to (count, Qnil); > Stefan -- Alan Mackenzie (Nuremberg, Germany).