emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Unbalanced change hooks (part 2)


From: Eli Zaretskii
Subject: Re: Unbalanced change hooks (part 2)
Date: Tue, 02 Aug 2016 17:57:18 +0300

> Date: Tue, 2 Aug 2016 10:15:49 +0000
> From: Alan Mackenzie <address@hidden>
> Cc: address@hidden, address@hidden, address@hidden
> 
> 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.)
 (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.  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.

> 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.  The intent of the 'prepare'
parameter is quite clear, and is consistently followed by all the
callers of these functions.

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



reply via email to

[Prev in Thread] Current Thread [Next in Thread]