Re: Unbalanced change hooks (part 2)

[Eli Zaretskii]

> 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.

> 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 future, 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.

> (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.

> 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.

> >       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.

> 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.

> 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.