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

[Daniel Colascione]

On 08/11/2016 09:43 AM, Stefan Monnier wrote:
> > That is the current status, yes.  In the bug which gave rise to this
> > discussion, bug #24094, a certain change did not call b-c-f at all.
>
> Right, but that's a bug, not a misfeature we want to document.
>
> > The Elisp manual, up until yesterday, documented implicitly that b-c-f
> > and a-c-f were paired.
>
> No: you read it as documenting this implicitly, but that's a misunderstanding.

Alan's interpretation is the text is the natural one, and it's the one I 
had as well. It's a technical specification, not some kind of allegory. 
It's meant to be taken literally. There is nothing in the old manual to 
hint at the more complex reality of the situation, and the additional 
text just confuses the issue.

Besides, you haven't fixed the docstring, which still suggests that 
b-c-f is called before every change. (And a "change" must be anything 
that results in a-c-f being called.)

Alan is absolutely correct that current Emacs behavior should count as a 
bug. The behavior Alan wants, which is also the behavior XEmacs 
provides, and the behavior the manual suggestions on plain reading, is 
also the most elegant and useful behavior for these hooks.

Eli's original argument for not balancing b-c-f with a-c-f is the 
delicacy of other Emacs code, but this specific change is almost 
certainly safe, considering that b-c-f is almost always balanced with 
a-c-f already. Alan's given plenty examples of legitimate pieces of code 
that can break if b-c-f is not called for a given a-c-f.

What pieces of code could conceivably break if Emacs balances 
currently-unbalanced a-c-f calls?

> > > Furthermore there is no evidence that you "MUST".
> > > I gave various examples of ways you can live with only a-c-f.
> > Vague hand-waving is what I remember.
>
> That's because you don't want to think about it seriously: Of course
> it's not in the form of a patch to CC-mode that passes all your tests
> plus various performance assessments, no.  But those "vague hand-waving"
> refer to techniques used in actual code in various major modes facing
> similar problems.
>
> > You know full well what I mean.  By the time you get to a-c-f the
> > deletion as announced is a hollowed out husk, all its details except for
> > its position and size having been lost.
>
> As mentioned in my so-called "hand-waving", any details you may need can
> be stored somewhere for use.

Is it really better to force that complexity (which, in the limit, 
amounts to full shadow buffers) onto mode authors instead of changing 
Emacs to balance b-c-f with a-c-f 100% of the time instead of 99%?

> But there's no reason your code could *require* this data for correct
> behavior, since your code also has to handle the more general case where
> all the text after BEG has been replaced by something else which may or
> may not include similar contents and may or may not already include some
> text-properties like `syntax-table'.
>
> > What you and Eli are asserting is that one NEVER IN ANY CIRCUMSTANCES
> > needs to know the full details of a buffer modification, and no program
> > now or in the future ever will.
>
> Exactly.  And that's because the code has to handle the previously
> mentioned general case anyway.
>
> > With the recent change in documentation, Emacs 25.1 has become a less
> > powerful programming system, one in which these details cannot
> > be determined.
>
> Nope.  The documentation is just more honest than before.

It's also self-contradictory: upon calling syntax-ppss, Emacs installs a 
before-change-function, which in a mode that perfectly legitimately has 
an after-change-function, violates the rule that we use one set of 
functions or another.