Re: Unbalanced change hooks (part 2)

[Alan Mackenzie <acm@muc.de>]

Hello, Eli.

On Tue, Aug 02, 2016 at 05:57:18PM +0300, Eli Zaretskii wrote:
> > Date: Tue, 2 Aug 2016 10:15:49 +0000
> > From: Alan Mackenzie <acm@muc.de>
> > Cc: ofv@wanadoo.es, rcopley@gmail.com, emacs-devel@gnu.org

> > I think the particular instance IS grossly and conspicuously bad.  The
> > resulting code is so difficult to maintain that (i) our
> > before-change-functions/after-change-functions mechanism is broken, in
> > that the b-c-f hook is only called for some changes, not all changes;
> > (ii) Eli Z. has forcefully declined my offer to fix this, on the grounds
> > that the pertinent code (in .../src/insdel.c) is so fragile that any
> > attempt to fix it will inevitably introduce hidden bugs elsewhere.

> I'm sorry, but the above doesn't match my views and opinions on this
> matter, so I would like to express them as clearly as possible:

>  (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.  I have
read the code, and what I see is not "works as designed" but "failure
consequently to adhere to the design".  b-c-f is used infrequently
enough that it took CC Mode to expose the failure.

>  (ii) I never said the code which implements the support for these
>       hooks is "so fragile that any attempt to fix it will inevitably
>       introduce hidden bugs".  The code in insdel.c is rock-solid,
>       and I feel confident when I make changes there (as indeed I did
>       several times during the last year).  What I fear is not the
>       fragility of insdel.c, it's the unintended consequences of
>       changing the aspects of it and of its callers that are clearly
>       against the original design.

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.
(That's leaving aside precisely what qualifies as a "buffer
modification" and what doesn't.)

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.

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

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.

> > This `prepare' parameter is central to the difficulties of fixing/not
> > being able to fix the b-c-f/a-c-f mechanism.

> I don't think the mechanism needs fixing.

We'll have to carry on disagreeing about this.  For what it's worth, I
accept that it's not going to get fixed.

> The intent of the 'prepare' parameter is quite clear, and is
> consistently followed by all the callers of these functions.

I don't find the intent clear, since prepare_to_modify_buffer is a
mishmash of miscellaneous things, rather than a "do one thing and do it
well".  

If this `prepare' mechanism hadn't been used, but instead the functions
simply called where they were needed, then adding in the b-c-f calls
could have been trivial.

> What we need is find the best way of fixing CC Mode based on this or
> some other mechanism.

Yes.  CC Mode and the other 13 files.el too.

-- 
Alan Mackenzie (Nuremberg, Germany).