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

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

>> It is guaranteed, modulo bugs (the insert-file-contents (with
>> replace) case).
> Sure. The current implementation provides neither property though.

That's OK.  We're talking about the doc and the intended behavior.
Bugs are part of life.

>> 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?
> Same as Alan's --- examining the buffer before the change to see which
> brace-delimited scopes need to be invalidated.

I need more details.

> Emacs core also contains a lot of code that looks fragile under
> asymmetric b-c-f behavior: see tex-mode, org, and viper. (I'm not
> claiming that these modes are broken, but it's not obvious from the
> code that they aren't broken.)

tex-mode's b-c-f doesn't care about when or how any a-f-c gets run or if
it even get run at all.  It just sets some text-properties lazily
(because those properties are only needed when and where a change
happens, so they can be set via b-c-f rather than setting them eagerly
over the whole buffer right from the start).

No idea about org, as for Viper I'm not completely sure what it's trying
to do, but the code looks fiddly (with or without b/a-c-f's asymmetry)
so I'd expect breakage in corner cases anyway.

>> Almost: I don't see the need to change the doc because I don't see where
>> it misleads.
> b-c-f and a-c-f are symmetric in name and signature. b-c-f is documented as
> "List of functions to call before each text change." a-c-f is documented as
> "List of functions to call after each text change." The elisp manual
> documentation is similarly symmetric. This symmetry produces an expectation
> that the behavior is symmetric, and this expectation is reinforced by how
> the observed behavior is almost always symmetric in practice. Symmetric
> behavior here is also what intuitively makes sense.
>
> Please believe me when I say that the current documentation misleads.

OK, so you agree that the documentation does not say they are
properly paired.  You just extrapolate it.

I agree there's such a risk that the reader extrapolates in the way you
described, which is why the current documentation states explicitly that
they're not always paired:

      Do @emph{not} expect the before-change hooks and the after-change
    hooks be called in balanced pairs around each buffer change.  Also

I think it's pretty clear.

> A feature that almost works as expected --- except in certain weird cases
> where it corrupts your state --- is at best an attractive nuisance.

I don't claim that the lack of symmetry is a feature.  But fixing it is
not easy.

Furthermore, the cases I've seen of code designs which wants this
behavior tend to be brittle and overly complicated, compared to
alternative designs which don't rely on this behavior.

I guess a way to "fix" it would be to add a random fudge factor to the
b-c-f calls, plus add random dummy calls to b-c-f, and sprinkle the
lisp/*.el code with combine-after-change-calls.  This way, the "properly
paired up" case will be much more exceptional.

> I was under the impression that Eli's concern was with the effect of
> the b-c-f change itself, not with bugs that might be introduced by
> the change.

I can't speak for Eli, but at least that's not my worry.

> I'm confident that with enough review, the core code could be changed
> to make b-c-f and a-c-f symmetric without causing weird
> bugs elsewhere.

Sure.  But I see more benefits in changing the few places that
mistakenly rely on this pairing.


        Stefan