From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Re: Unbalanced change hooks (part 2) [Documentation fix still remaining] Date: Thu, 01 Sep 2016 16:46:29 +0300 Message-ID: <83lgzbg2bu.fsf@gnu.org> 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> Reply-To: Eli Zaretskii NNTP-Posting-Host: blaine.gmane.org X-Trace: blaine.gmane.org 1472737665 31903 195.159.176.226 (1 Sep 2016 13:47:45 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Thu, 1 Sep 2016 13:47:45 +0000 (UTC) Cc: emacs-devel@gnu.org To: Stefan Monnier Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Thu Sep 01 15:47:38 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 1bfSL6-0006y5-LV for ged-emacs-devel@m.gmane.org; Thu, 01 Sep 2016 15:47:32 +0200 Original-Received: from localhost ([::1]:37208 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bfSL4-0006Er-Bz for ged-emacs-devel@m.gmane.org; Thu, 01 Sep 2016 09:47:30 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:35897) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bfSK9-0006Ef-Iq for emacs-devel@gnu.org; Thu, 01 Sep 2016 09:46:34 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1bfSK5-0007l0-EJ for emacs-devel@gnu.org; Thu, 01 Sep 2016 09:46:32 -0400 Original-Received: from fencepost.gnu.org ([2001:4830:134:3::e]:60784) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bfSK5-0007kr-Bs; Thu, 01 Sep 2016 09:46:29 -0400 Original-Received: from 84.94.185.246.cable.012.net.il ([84.94.185.246]:4778 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_128_CBC_SHA1:128) (Exim 4.82) (envelope-from ) id 1bfSK4-00022i-FM; Thu, 01 Sep 2016 09:46:29 -0400 In-reply-to: (message from Stefan Monnier on Tue, 30 Aug 2016 14:27:29 -0400) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 2001:4830:134:3::e 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:207063 Archived-At: > From: Stefan Monnier > Date: Tue, 30 Aug 2016 14:27:29 -0400 > > > 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. I was not referring to this text, I was referring to our discussion. > 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 don't think it's an improvement. It replaces specific practical advice with abstract principle whose relation to practice might not be clear to some. Really, Stefan, after all these years, I'd expect you to trust me a bit more on documentation issues.