Re: Lisp primitives and their calling of the change hooks

[Alan Mackenzie <acm@muc.de>]

Hello, Stefan.

On Tue, Jan 09, 2018 at 15:07:58 -0500, Stefan Monnier wrote:
> > 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.

> But not incorrect.

> > If the decompression fails, we need to balance that b-c-f with
> > a "fake" a-c-f call.

> No, we don't.  It's still within the rules to announce an upcoming
> change with b-c-f and then not to carry through (i.e. not make any
> changes and not call a-c-f).

It's debatable whether it's within the rules or not.  The rules, which
we so carefully crafted a few days ago, say, in part; "The arguments to
`before-change-functions' will enclose a region in which the individual
changes are made, ...".  There will never be any changes made in the
quasi-deleted region, so to leave it without a balanceing a-c-f call
could be construed as against the rules.

I'm not saying it's a sensible debate to have, though.  More to the
point is that the b-c-f call may have made changes to the buffer which
need to be undone.  (Somebody, sometime, is going to try calling this
primitive in a C++ Mode buffer just to see what happens.  What they
should see is no buffer change, particularly not in the text
properties.)

Although, with unbalanced b/a-c-f being permitted anyway, for a mode
whose b-c-f does make buffer changes, there'll have to be, say, an entry
in post-command-hook anyway, to catch these unbalanced calls.

>         Stefan

-- 
Alan Mackenzie (Nuremberg, Germany).