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

[Daniel Colascione <dancol@dancol.org>]

On August 30, 2016 11:30:09 AM PDT, Alan Mackenzie <acm@muc.de> wrote:
>Hello, Daniel.
>
>On Tue, Aug 30, 2016 at 11:17:48AM -0700, Daniel Colascione wrote:
>> On 08/30/2016 11:06 AM, Daniel Colascione wrote:
>> > On 08/30/2016 11:01 AM, Alan Mackenzie wrote:
>
>> >> On Tue, Aug 30, 2016 at 10:46:44AM -0700, Daniel Colascione wrote:
>> >>> On 08/30/2016 10:42 AM, Eli Zaretskii wrote:
>> >>>>> Cc: monnier@iro.umontreal.ca, emacs-devel@gnu.org
>> >>>>> From: Daniel Colascione <dancol@dancol.org>
>> >>>>> Date: Tue, 30 Aug 2016 10:27:45 -0700
>
>> >>>>> +The region given to each of these functions is a conservative
>> >>>>> +approximation of the region about to changed.  After running
>the
>> >>>>> +before-change-functions, Emacs will make zero or more
>fine-grained
>> >>>>> +buffer changes and run after-change-functions for each.  Do
>not
>> >>>>> expect
>> >>>>> +before-change-functions and after-change-functions to be
>called in
>> >>>>> +balanced pairs.
>
>> >>>> The last sentence here is repeated afterwards, for no good
>reason.
>> >>>> (Also, the markup is missing, but that's just an aside.)
>
>> >>> I figured it was a good idea to highlight this fact directly in
>the
>> >>> variable documentation blob. I can add a "see below" link.
>
>> >> Why are you advocating this?  It is not true.
>
>> It's not true. If it's true except for one time in a million, it's
>not 
>> true.
>
>That's straying off-topic into philosophy.

Just defining terms

>
>> Programs need to be written for the world we inhabit, not the one 
>> we want. Relying on behavior that's usually but not always the case
>is 
>> antithetical to software robustness.
>
>Coming back to the concrete, your proposed way of expressing things
>would prevent future hackers from using b-c-f and a-c-f together the
>way
>that we do.  Is that what you want?

It doesn't prevent them per second: it just forces them to be more careful. I'd prefer that these hooks work the way we both want, but if that's not the case, I'd rather not mislead developers. It's not the documentation that prevents this use, but the Emacs core