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

[Stefan Monnier <monnier@IRO.UMontreal.CA>]

> 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.

>> 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.

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.

> If you want to try and construct a CC Mode which disregards deletions,
> you are welcome.  I won't stand in your way.  But I will try and break it.

I expect no less.

>> .... and I understand that you might prefer to try and live with it
>> than to go back and rethink it, but it's still a bad design (nor is it
>> the only bad design we have in Emacs, of course).
> You've been libelling my design for longer than I can remember.
> It's different from how you'd try to do it, that's all.

No, that's not all.  It's based on an invalid assumption about b-c-f and
a-c-f, and even if that assumption was true I contend that it leads to
more complex code.

It probably has some performance advantages in some cases, of course.
By I doubt it has a performance advantage "on average".

> It's a straightforward and obvious distillation of requirements and
> Emacs's documented features.

No idea what you mean by that.

> You recently admitted you'd never tried to build anything that way, so
> you're just saying "my way is better".

I also tried to replace in CC-mode "your way" with mine and found mine
to be simpler.


        Stefan