emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Alan Mackenzie
Subject: Re: Unbalanced change hooks (part 2) [Documentation fix still remaining]
Date: Tue, 30 Aug 2016 18:30:09 +0000
User-agent: Mutt/1.5.24 (2015-08-30)

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: address@hidden, address@hidden
> >>>>> From: Daniel Colascione <address@hidden>
> >>>>> 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.

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

-- 
Alan Mackenzie (Nuremberg, Germany).



reply via email to

[Prev in Thread] Current Thread [Next in Thread]