Re: Lisp primitives and their calling of the change hooks

[Alan Mackenzie <acm@muc.de>]

Hello, Stefan.

On Thu, Jan 11, 2018 at 15:15:49 -0500, Stefan Monnier wrote:
> >> >> I'm very far from convinced about the "elaborate special handling".
> >> > Well, you agree that there're no advantages to having unbalanced change
> >> > hooks,
> >> No I don't.
> > You don't?

> How can you be surprised?

Not surprised.  I've just spent the last three posts, and quite a few
before that, trying to get you to tell me in detail what's desirable
about unbalanced change hooks.  I'd genuinely like to know, since I
couldn't (and still can't) see this.

[ .... ]

> > What, then, might those advantages be,

> Implementation flexibility, of course (which apparently Eli doesn't
> want to take advantage of very much).

What flexibility?  What can you do with unbalanced hooks that you can't
do when you constrain yourself to balance them?  Are you talking about
flexibility in writing primitives or in using them?  Can you give me an
example?

> > and in what conditions would those advantages outweigh the known
> > disadvantages in allowing unbalanced change hooks?

> What known disadvantages?

That b-c-f and a-c-f can't work smoothly together in partnership.
Instead, at the moment, to be rigorous, code must use non-nice artifices
to cope with the rare occurences of unbalanced change hook calls.  You
know CC Mode does this.  An example, in C++ Mode, is where the b-c-f
function removes balanced paren syntax-table text properties from
template delimiters when half of a pair is about to be deleted.  This
mechanism expects a matching a-c-f so as to put them back where needed.

Indeed, rigorous pairing of b-c-f and a-c-f would increase the
flexibility of programs using them, not decrease it.

>         Stefan

-- 
Alan Mackenzie (Nuremberg, Germany).