Re: Unbalanced change hooks (part 2)

[Alan Mackenzie]

Hello, Eli.

On Tue, Aug 02, 2016 at 08:17:35PM +0300, Eli Zaretskii wrote:
> > Date: Tue, 2 Aug 2016 16:55:45 +0000
> > Cc: address@hidden, address@hidden, address@hidden, address@hidden
> > From: Alan Mackenzie <address@hidden>

> > >  (i)  I disagree that the modification-hooks mechanism is broken.  It
> > >       works as designed; if you read the code, you see that very
> > >       clearly.  (Alan disagrees with the design, but that's another
> > >       matter.)

> > I thought we'd already agreed that no rational design would omit the
> > before-change-hooks call from an arbitrary subset of changes.

> No, I don't think there was such an agreement.  The set of changes for
> which before-change-functions are not called is not arbitrary.

Would you please characterize these circumstances in a way useful for
people considering the use of before-change-functions.  If you like, I
can then modify Elisp's "Change Hooks" with that information.

> > To me it's perfectly clear the original design was, for each buffer
> > modification there is exactly one invocation of b-c-f and one of a-c-f.

> If such an original design existed in the distant past, it was long
> ago (as in 20 years or more) replaced with what we basically see
> today, where every change always triggers a call to
> after-change-functions, but only some (the majority, but not all)
> trigger the call to before-change-functions.

>From the point of view of design, what is the benefit in not calling
b-c-f for that subset of circumstances?

> > (That's leaving aside precisely what qualifies as a "buffer
> > modification" and what doesn't.)

> I don't think it can be left aside, if you want to understand the
> rationale.

I do want to.  Currently, I'm not terribly concerned about exactly
whether some change qualifies as a buffer modification or not.  Just that
when it does, and only half of the change hooks are called, I'd like to
know why.

> > The fact that we're too scared to make the simple changes to adhere to
> > the design (as documented in the Elisp manual) is precisely what
> > "fragile code" means.  And "call b-c-f for all changes" should be a
> > simple change.

> We are not scared.  We (I) simply don't want to do that, at least not
> yet.  When non-trivial changes were needed in insdel.c, they were done
> without fear, including lately by yours truly.

OK.

> > >       Doing that for introducing some important new feature would be
> > >       justified, but doing that because CC Mode made incorrect
> > >       assumptions about how this mechanism works is IMO wrong.

> > CC Mode didn't make incorrect assumptions - it followed rigourously the
> > feature as documented in the Elisp manual.

> The ELisp manual doesn't promise that these hooks will be called in
> balanced pairs.

It does.  before-change-functions is described as:

    .... a list of functions to call before any buffer modification.

after-change-functions is likewise described as:

    .... a list of functions to call after any buffer modification.

.  It may not explicitly say they are paired, but it says each hook is
called after every modification.  This naturally pairs them up.

As a native English speaker, the only alternative interpretation I see
(which is absurd) is that Emacs will call each of these hooks once, after
any buffer modification Emacs choses.  I see no way out of the conclusion
that both of these hooks are to be called after each and every buffer
modification.

> > The implication of your last paragraph is that before using any core
> > feature, a Lisp hacker should first examine its implementation to
> > make sure the documentation is correct.  This is absurd.

> No, that's life.  What do you think I did before embarking on writing
> the bidirectional display?  A lot of code reading, a lot of
> discussions with Gerd Moellmann, more code reading, etc.  All that was
> needed even though the display engine has much more detailed overview
> comments than almost any other part of Emacs.

bidi is a somewhat special case.  Somebody considering the use of the
change hooks should be able to rely on their documentation, without
having to read and understand fileio.c and insdel.c.  

> > Anyhow, it's not just CC Mode.  As already discussed, there are 13 other
> > files which use before-change-functions, and some of these uses are
> > going to assume it works as documented, just as CC Mode did.  Sporadic
> > failures are going to occur in some of these other places, due to those
> > hook functions sometimes not being called.

> I will believe that when I see specific bug reports about those other
> packages.

You won't see them, and neither will I, because they'll be sporadic bugs
with wierd consequences, maybe the odd corrupted buffer once in a blue
moon.  Any that make it to a bug report will end up being closed as not
reproducible.  Other times, something will just fail to work, the user will
gently curse Emacs and try again.  We can just pretend those other files
are OK, I suppose.  A lot of them probably actually will be.

-- 
Alan Mackenzie (Nuremberg, Germany).