From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Stefan Monnier Newsgroups: gmane.emacs.devel Subject: Re: Unbalanced change hooks (part 2) [Documentation fix still remaining] Date: Tue, 30 Aug 2016 14:27:29 -0400 Message-ID: References: <20160811112951.GA2154@acm.fritz.box> <7e1478b6-cf00-fcbf-8c24-43bdaa57e2b6@dancol.org> <415d1cca-f32c-624e-a4be-9aadcf8a0f17@dancol.org> <83inujbpek.fsf@gnu.org> <20160830171222.GA6672@acm.fritz.box> <5857ab7e-e85c-c6ae-ba1a-b1337ae57f2c@dancol.org> <83fupmm9ul.fsf@gnu.org> <67e1e007-c944-b91e-6c4b-b06b51beddc1@dancol.org> <83bn0am91r.fsf@gnu.org> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: blaine.gmane.org 1472721531 30039 195.159.176.226 (1 Sep 2016 09:18:51 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Thu, 1 Sep 2016 09:18:51 +0000 (UTC) User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.1.50 (gnu/linux) To: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Thu Sep 01 11:18:47 2016 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1bfO90-0007J8-4V for ged-emacs-devel@m.gmane.org; Thu, 01 Sep 2016 11:18:46 +0200 Original-Received: from localhost ([::1]:35797 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bfO90-0001cu-Vp for ged-emacs-devel@m.gmane.org; Thu, 01 Sep 2016 05:18:47 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:55661) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bfO8p-0001cY-OE for emacs-devel@gnu.org; Thu, 01 Sep 2016 05:18:36 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1bfO8k-0005Ac-Dq for emacs-devel@gnu.org; Thu, 01 Sep 2016 05:18:34 -0400 Original-Received: from [195.159.176.226] (port=39224 helo=blaine.gmane.org) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bfO8k-0005AI-6f for emacs-devel@gnu.org; Thu, 01 Sep 2016 05:18:30 -0400 Original-Received: from list by blaine.gmane.org with local (Exim 4.84_2) (envelope-from ) id 1beni4-0000aQ-8L for emacs-devel@gnu.org; Tue, 30 Aug 2016 20:24:32 +0200 X-Injected-Via-Gmane: http://gmane.org/ Original-Lines: 39 Original-X-Complaints-To: usenet@blaine.gmane.org Cancel-Lock: sha1:Ggg1M4okikI+YJpf+t+Zk8eyd7U= X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 195.159.176.226 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.org gmane.emacs.devel:207049 Archived-At: > 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