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: Mon, 8 Jan 2018 19:24:15 +0000 Message-ID: <20180108192415.GA5531@ACM> References: <20180107120859.GB22254@ACM> <20180107135629.GC22254@ACM> <83mv1p8vki.fsf@gnu.org> <83bmi58sao.fsf@gnu.org> <20180107194845.GE22254@ACM> <838td98mqe.fsf@gnu.org> <20180107211055.GF22254@ACM> <837est81bl.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 1515439632 11662 195.159.176.226 (8 Jan 2018 19:27:12 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Mon, 8 Jan 2018 19:27:12 +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 Mon Jan 08 20:27:08 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 1eYd4c-0002cn-P2 for ged-emacs-devel@m.gmane.org; Mon, 08 Jan 2018 20:27:06 +0100 Original-Received: from localhost ([::1]:53533 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1eYd6c-0005Qg-2O for ged-emacs-devel@m.gmane.org; Mon, 08 Jan 2018 14:29:10 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:38734) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1eYd6U-0005QO-Kq for emacs-devel@gnu.org; Mon, 08 Jan 2018 14:29:03 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1eYd6R-0004df-FG for emacs-devel@gnu.org; Mon, 08 Jan 2018 14:29:02 -0500 Original-Received: from colin.muc.de ([193.149.48.1]:38745 helo=mail.muc.de) by eggs.gnu.org with smtp (Exim 4.71) (envelope-from ) id 1eYd6R-0004d5-79 for emacs-devel@gnu.org; Mon, 08 Jan 2018 14:28:59 -0500 Original-Received: (qmail 2929 invoked by uid 3782); 8 Jan 2018 19:28:58 -0000 Original-Received: from acm.muc.de (p548C71E9.dip0.t-ipconnect.de [84.140.113.233]) by colin.muc.de (tmda-ofmipd) with ESMTP; Mon, 08 Jan 2018 20:28:57 +0100 Original-Received: (qmail 5996 invoked by uid 1000); 8 Jan 2018 19:24:15 -0000 Content-Disposition: inline In-Reply-To: <837est81bl.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:221724 Archived-At: Hello, Eli. On Mon, Jan 08, 2018 at 05:41:02 +0200, Eli Zaretskii wrote: > > Date: Sun, 7 Jan 2018 21:10:55 +0000 > > Cc: monnier@iro.umontreal.ca, emacs-devel@gnu.org > > From: Alan Mackenzie > > > Like I said, I think we should have only one pair of hooks, like we > > > have in replace_range. > > OK. This is slightly more awkward: del_range needs to be replaced by > > del_range_2, so as not to get an extra call to signal_after_change. > You need a call to update_compositions after del_range_2, to mimic > what del_range does, I think. Yes, I think so to (though I'm only vaguely aware of what compositions are ;-). See below. > > There is also no a-c-f call if the decompression exits with an error. > You mean, if the user quits? That throws to top level, so it would be > wrong to invoke any after-change hooks, and unwind_decompress will > call the hooks for the partially uncompressed data. Do we need more? I was thinking more of when the compressed text is corrupt and the decompression routines report an error. With the current version (see below), I simulate an error with (zlib-decompress-region (point-min) (1- (point-max))) , i.e. chopping the last byte off the buffer. (I am using my Linux configuration from /proc/config.gz for all this.) This produces these hook calls: (1 22016) (22016 118057) (22016 22016 96041) , the first being the opening modify_text(), and the last two being the deletion of the incomplete decompressed region by a call to del_range() from an unwind-protect. The (1 22016) b-c-f is thus unbalanced when this happens. I'm asking you to consider again having two pairs of hook calls in this primitive (as, for example, base64-decode-region does). That way we need only signal the b-c-f for the deletion after the decompression has worked, and we know we are going to follow through with the deleteion. I think an aborted decompression operation would also be easier to close off with an a-c-f with this strategy. Here's the amended patch from last night with update_compositions in: diff --git a/src/decompress.c b/src/decompress.c index 41de6da1dd..eebaa2eb30 100644 --- a/src/decompress.c +++ b/src/decompress.c @@ -24,6 +24,7 @@ along with GNU Emacs. If not, see . */ #include "lisp.h" #include "buffer.h" +#include "composite.h" #include @@ -141,6 +142,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 (istart, iend); + move_gap_both (iend, iend); stream.zalloc = Z_NULL; @@ -196,7 +201,11 @@ This function can be called only in unibyte buffers. */) unwind_data.start = 0; /* Delete the compressed data. */ - del_range (istart, iend); + del_range_2 (istart, istart, /* byte and char offsets are the same. */ + iend, iend, 0); + + signal_after_change (istart, iend - istart, unwind_data.nbytes); + update_compositions (istart, istart, CHECK_HEAD); return unbind_to (count, Qt); } > Thanks. -- Alan Mackenzie (Nuremberg, Germany).