[Top][All Lists]

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

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

From: Stefan Monnier
Subject: Re: Unbalanced change hooks (part 2) [Documentation fix still remaining]
Date: Tue, 30 Aug 2016 14:27:29 -0400
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/25.1.50 (gnu/linux)

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

FWIW, when I read

    hooks be called in balanced pairs around each buffer change.  Also
    don't expect the before-change hooks to be called for every chunk of
    text Emacs is about to delete.  These hooks are provided on the

I do understand this to mean "b-c-f is just unreliable" and more
specifically it does sound to me like it refers to the known
insert-file-contents bug.  If that was not your intention, then consider
this as evidence that a rewording could be beneficial.

>> My proposed description highlights how the b-c-f region contains the 
>> a-c-f regions. I understand that you believe that the existing 
>> documentation communicates this fact, but I strongly disagree. The 
>> relationship between the b-c-f region and the a-c-f regions needs to be 
>> spelled out explicitly.
> They cannot be spelled out explicitly without going into a lot more
> internal details that are inappropriate for the Lisp-level manual.

He considers his text to spell it in enough detail.  So unless you
disagree with the text itself, I think his text is an improvement: you
both agree with the validity and level of precision of the description
in his new text, which is not the case with the current text.

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

syntax-ppss relies on it, so we had better make sure we can rely on
it ;-0


reply via email to

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