[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
Stefan
- Re: Unbalanced change hooks (part 2) [Documentation fix still remaining],
Stefan Monnier <=
- Re: Unbalanced change hooks (part 2) [Documentation fix still remaining], Stefan Monnier, 2016/09/01
- Re: Unbalanced change hooks (part 2) [Documentation fix still remaining], Stefan Monnier, 2016/09/01
- Re: Unbalanced change hooks (part 2) [Documentation fix still remaining], Stefan Monnier, 2016/09/01
- Re: Unbalanced change hooks (part 2) [Documentation fix still remaining], Stefan Monnier, 2016/09/01
- Re: Unbalanced change hooks (part 2) [Documentation fix still remaining], Davis Herring, 2016/09/01