From: Alan Mackenzie <acm@muc.de>
To: Eli Zaretskii <eliz@gnu.org>
Cc: monnier@iro.umontreal.ca, emacs-devel@gnu.org
Subject: Re: Lisp primitives and their calling of the change hooks
Date: Tue, 9 Jan 2018 19:53:57 +0000 [thread overview]
Message-ID: <20180109195357.GA3869@ACM> (raw)
In-Reply-To: <83h8rw6oio.fsf@gnu.org>
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 <acm@muc.de>
> > > > 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).
next prev parent reply other threads:[~2018-01-09 19:53 UTC|newest]
Thread overview: 66+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-01-03 12:45 Lisp primitives and their calling of the change hooks Alan Mackenzie
2018-01-03 21:51 ` Stefan Monnier
2018-01-04 15:51 ` Alan Mackenzie
2018-01-04 18:16 ` Stefan Monnier
2018-01-04 21:11 ` Alan Mackenzie
2018-01-04 21:36 ` Stefan Monnier
2018-01-06 15:18 ` Alan Mackenzie
2018-01-06 15:51 ` Stefan Monnier
2018-01-06 16:18 ` Eli Zaretskii
2018-01-06 19:06 ` Alan Mackenzie
2018-01-06 20:24 ` Alan Mackenzie
2018-01-07 11:36 ` Alan Mackenzie
2018-01-07 11:49 ` Eli Zaretskii
2018-01-07 12:08 ` Alan Mackenzie
2018-01-07 13:56 ` Alan Mackenzie
2018-01-07 15:21 ` [SUSPECTED SPAM] " Stefan Monnier
2018-01-07 16:47 ` Eli Zaretskii
2018-01-07 17:50 ` Stefan Monnier
2018-01-07 17:58 ` Eli Zaretskii
2018-01-07 19:04 ` Stefan Monnier
2018-01-07 19:48 ` Alan Mackenzie
2018-01-07 19:58 ` Eli Zaretskii
2018-01-07 21:10 ` Alan Mackenzie
2018-01-08 3:41 ` Eli Zaretskii
2018-01-08 19:24 ` Alan Mackenzie
2018-01-08 21:15 ` Eli Zaretskii
2018-01-08 22:24 ` Stefan Monnier
2018-01-09 3:55 ` Eli Zaretskii
2018-01-09 13:30 ` Stefan Monnier
2018-01-09 18:50 ` Eli Zaretskii
2018-01-09 19:53 ` Alan Mackenzie [this message]
2018-01-09 20:05 ` Eli Zaretskii
2018-01-10 18:29 ` Alan Mackenzie
2018-01-12 16:40 ` Alan Mackenzie
2018-01-09 20:07 ` Stefan Monnier
2018-01-10 18:45 ` Alan Mackenzie
2018-01-10 19:30 ` Stefan Monnier
2018-01-10 19:48 ` Alan Mackenzie
2018-01-10 20:33 ` Stefan Monnier
2018-01-10 21:03 ` Alan Mackenzie
2018-01-11 13:36 ` Stefan Monnier
2018-01-11 17:39 ` Alan Mackenzie
2018-01-11 19:35 ` Stefan Monnier
2018-01-11 19:46 ` Alan Mackenzie
2018-01-11 20:15 ` Stefan Monnier
2018-01-11 21:20 ` Alan Mackenzie
2018-01-11 23:42 ` Stefan Monnier
2018-01-12 16:14 ` Alan Mackenzie
2018-01-10 22:06 ` Clément Pit-Claudel
2018-01-10 22:20 ` Alan Mackenzie
2018-01-08 4:29 ` Stefan Monnier
2018-01-07 17:54 ` Alan Mackenzie
2018-01-07 18:05 ` Eli Zaretskii
2018-01-05 6:55 ` Eli Zaretskii
2018-01-05 11:41 ` Alan Mackenzie
2018-01-05 13:00 ` Eli Zaretskii
2018-01-05 13:34 ` Alan Mackenzie
2018-01-05 14:08 ` Eli Zaretskii
2018-01-05 15:54 ` Alan Mackenzie
2018-01-05 16:50 ` Stefan Monnier
2018-01-05 17:38 ` Alan Mackenzie
2018-01-05 18:09 ` Stefan Monnier
2018-01-05 19:53 ` Eli Zaretskii
2018-01-05 22:28 ` Stefan Monnier
2018-01-06 9:05 ` Eli Zaretskii
2018-01-06 15:26 ` Stefan Monnier
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.gnu.org/software/emacs/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20180109195357.GA3869@ACM \
--to=acm@muc.de \
--cc=eliz@gnu.org \
--cc=emacs-devel@gnu.org \
--cc=monnier@iro.umontreal.ca \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).