Re: Unbalanced change hooks (part 2) [Documentation fix still remaining]

[Stefan Monnier <monnier@iro.umontreal.ca>]

> 1) b-c-f isn't currently balanced with a-c-f in the insdel.c implementation

There's no guarantee that it be balanced, indeed.

> 2) b-c-f isn't currently guaranteed to be called at all before any given
> call to a-c-f (e.g., the C-x C-f case)

It is guaranteed, modulo bugs (the insert-file-contents (with replace) case).

> 2) the documentation suggests that a-c-f and b-c-f are balanced

I don't see where in the documentation it suggests it.

> 3) many people, Alan and me included, were under the impression that b-c-f
> and a-c-f were balanced and wrote code accordingly

Ah, so you too have code which makes this assumption.  Could you point
to it, explaining what it does and why it makes this assumption, so we
have a better picture of why it could be useful?

> AIUI, Eli's position is that the current behavior should not change at all,
> because making changes at this level is too risky.

I don't think he said "at all", but just that it's tricky to make such
changes, so they had better be backed by really good reasons.

> Your position is that #2 is a bug, but #1 is not, and the
> documentation needs to change.

Almost: I don't see the need to change the doc because I don't see where
it misleads.

> So what do you propose doing? Upthread, I explained why I think that fixing
> both #1 and #2 is pretty low-risk.

The problem is that changing the code w.r.t b/a-c-f might cause
*other* changes.  Clearly making them perfectly balanced and paired
should not *in itself* introduce any bugs: the bugs we're afraid of are
the accompanying unintended changes.


        Stefan