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: Tue, 9 Jan 2018 19:53:57 +0000 Message-ID: <20180109195357.GA3869@ACM> References: <83mv1p8vki.fsf@gnu.org> <83bmi58sao.fsf@gnu.org> <20180107194845.GE22254@ACM> <838td98mqe.fsf@gnu.org> <20180107211055.GF22254@ACM> <837est81bl.fsf@gnu.org> <20180108192415.GA5531@ACM> <83h8rw6oio.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 1515527838 20680 195.159.176.226 (9 Jan 2018 19:57:18 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Tue, 9 Jan 2018 19:57:18 +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 Tue Jan 09 20:57:14 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 1eZ017-0004BE-C2 for ged-emacs-devel@m.gmane.org; Tue, 09 Jan 2018 20:57:01 +0100 Original-Received: from localhost ([::1]:44376 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1eZ036-0004jC-UT for ged-emacs-devel@m.gmane.org; Tue, 09 Jan 2018 14:59:04 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:52272) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1eZ030-0004ic-AH for emacs-devel@gnu.org; Tue, 09 Jan 2018 14:58:59 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1eZ02w-0002rK-W7 for emacs-devel@gnu.org; Tue, 09 Jan 2018 14:58:58 -0500 Original-Received: from colin.muc.de ([193.149.48.1]:49663 helo=mail.muc.de) by eggs.gnu.org with smtp (Exim 4.71) (envelope-from ) id 1eZ02w-0002ow-PE for emacs-devel@gnu.org; Tue, 09 Jan 2018 14:58:54 -0500 Original-Received: (qmail 52385 invoked by uid 3782); 9 Jan 2018 19:58:51 -0000 Original-Received: from acm.muc.de (p548C76A2.dip0.t-ipconnect.de [84.140.118.162]) by colin.muc.de (tmda-ofmipd) with ESMTP; Tue, 09 Jan 2018 20:58:50 +0100 Original-Received: (qmail 5989 invoked by uid 1000); 9 Jan 2018 19:53:57 -0000 Content-Disposition: inline In-Reply-To: <83h8rw6oio.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:221766 Archived-At: Hello, Eli. On Mon, Jan 08, 2018 at 23:15:11 +0200, Eli Zaretskii wrote: > > Date: Mon, 8 Jan 2018 19:24:15 +0000 > > Cc: monnier@iro.umontreal.ca, emacs-devel@gnu.org > > From: Alan Mackenzie > > > > 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. > What do other primitives do when there's an error? That was never > reported in this discussion nor discussed, AFAICT. Up front, I see no > reason to keep any promises when that happens. base64-decode-region first decodes into a mallocked area of store, and if that has worked, inserts that area, then deletes the original. This gives two balanced pairs of b/a-c-f. If there's an error in decoding, there is neither buffer manipulation nor change hook calls. base64-encode-region does the same, using a mallocked area, and with two balanced pairs of b/a-c-f on success. > > The (1 22016) b-c-f is thus unbalanced when this happens. > If this is really important (and I don't see why it would be), you can > add a call to after-change-hooks before unbind_to of the error return. I think b/a-c-f calls should follow the rules whether a primitive operation succeeds or fails. This will enable operations partly done by before-change-functions to be backed out of without leaving a buffer in an inconsistent state. > > 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. > Is implementation convenience the only argument for Stefan's variant? > If so, it doesn't convince me, as the difference is barely tangible. The point is, that zlib-decompress-region is NOT an atomic change, and trying to treat it like one will tie us in knots. base64-de/encode-region ARE atomic from the buffer manipulation point of view - the replacement is either wholly done or not done at all, and this is known in advance. zlib-decompress-region, by contrast, always writes the decompressed bit into the buffer, then deletes a portion of buffer, but does not know in advance which bit of buffer will be deleted. (It depends on the success of the decompression operation.) The way I see it, to announce in advance that the original region will be deleted (by calling b-c-f for it) is suboptimal. If the decompression fails, we need to balance that b-c-f with a "fake" a-c-f call. There are several primitives which have more than one balanced b/a-c-f call in execution: examples are the base64- ones, move-to-column (when it replaces tabs), replace-buffer-contents, insert. (If you are interested enough, I can send you my test file.) However, I think we'll agree that we've already spent enough time debating this issue. If you still say one b/a-c-f pair for a (successful) zlib-decompress-region call, I will accept it, and fix the b/a-c-f call of the unsuccessful case. -- Alan Mackenzie (Nuremberg, Germany).