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

[Daniel Colascione]

On August 30, 2016 11:46:24 AM PDT, Eli Zaretskii <address@hidden> wrote:
>> Cc: address@hidden, address@hidden, address@hidden
>> From: Daniel Colascione <address@hidden>
>> Date: Tue, 30 Aug 2016 11:04:07 -0700
>> 
>> > You misunderstand what Stefan says.  He says not calling the
>> > before-change hook _at_all_ is a bug.  Not calling it for every
>chunk
>> > of deleted text is not necessarily a bug, if there's a previous
>less
>> > fine-grained call to the hook.  And that's what the text above
>> > conveys: that note every chunk to be deleted will have its own call
>to
>> > a hook.
>> 
>> So we're in agreement? True or false: b-c-f ought to be a
>conservative 
>> bound on subsequent a-c-f calls.
>
>Of course we are in agreement, about the essence.  Your text saus the
>same as mine, except that I don't find "conservative bound" to be more
>helpful than what I wrote, quite the contrary.

Your text is silent on the relationship between the regions given to b-c-f and 
the ones given to b-c-f. I don't understand what's so hard to see. My proposed 
change tightens the contract between the Emacs core and developers and does it 
in a way that doesn't impose additional requirements on the current 
implementation.


>
>> >> I strongly disagree. b-c-f is a perfectly good way to invalidate
>caches.
>> >
>> > So the readers need to know they cannot rely on that.
>> 
>> Why shouldn't they be able to rely on that? What *should* they use to
>
>> invalidate caches? Your position is not very clear to me.
>
>Stefan described the alternatives up-thread.


Those alternatives are all incredibly awkward