[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.
- Re: Unbalanced change hooks (part 2), (continued)
- Re: Unbalanced change hooks (part 2), Richard Stallman, 2016/08/01
- Re: Unbalanced change hooks (part 2), Alan Mackenzie, 2016/08/02
- Re: Unbalanced change hooks (part 2),
Eli Zaretskii <=
- Re: Unbalanced change hooks (part 2), Alan Mackenzie, 2016/08/02
- Re: Unbalanced change hooks (part 2), Eli Zaretskii, 2016/08/02
- Re: Unbalanced change hooks (part 2), Eli Zaretskii, 2016/08/02
- Re: Unbalanced change hooks (part 2), Alan Mackenzie, 2016/08/02
- Re: Unbalanced change hooks (part 2), Eli Zaretskii, 2016/08/02
- Re: Unbalanced change hooks (part 2), Alan Mackenzie, 2016/08/08
- Re: Unbalanced change hooks (part 2), Eli Zaretskii, 2016/08/08
- Re: Unbalanced change hooks (part 2), Alan Mackenzie, 2016/08/08
- Re: Unbalanced change hooks (part 2), Eli Zaretskii, 2016/08/08
- Re: Unbalanced change hooks (part 2), Alan Mackenzie, 2016/08/08