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, 18 Aug 2016 17:26:03 +0300 Message-ID: <83mvkaduh0.fsf@gnu.org> References: <83fuqnm6og.fsf@gnu.org> <83eg67m3aq.fsf@gnu.org> <20160808143614.GA7208@acm.fritz.box> <83mvkni7xf.fsf@gnu.org> <20160808165449.GB7208@acm.fritz.box> <83d1lji3ih.fsf@gnu.org> <20160808184223.GC7208@acm.fritz.box> <838tw7hyk2.fsf@gnu.org> <20160808195459.GD7208@acm.fritz.box> <83tweugeu9.fsf@gnu.org> <20160809163814.GD4893@acm.fritz.box> <83inv9hkjd.fsf@gnu.org> <83h9ashfgx.fsf@gnu.org> <831t1wharr.fsf@gnu.org> Reply-To: Eli Zaretskii NNTP-Posting-Host: blaine.gmane.org X-Trace: blaine.gmane.org 1471530420 19171 195.159.176.226 (18 Aug 2016 14:27:00 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Thu, 18 Aug 2016 14:27:00 +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 Aug 18 16:26:55 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 1baOHX-0004en-HP for ged-emacs-devel@m.gmane.org; Thu, 18 Aug 2016 16:26:55 +0200 Original-Received: from localhost ([::1]:52978 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1baOHU-0007EH-JS for ged-emacs-devel@m.gmane.org; Thu, 18 Aug 2016 10:26:52 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:60712) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1baOGh-0007CG-8b for emacs-devel@gnu.org; Thu, 18 Aug 2016 10:26:04 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1baOGd-0005bF-WB for emacs-devel@gnu.org; Thu, 18 Aug 2016 10:26:03 -0400 Original-Received: from fencepost.gnu.org ([2001:4830:134:3::e]:60465) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1baOGd-0005b3-Sc; Thu, 18 Aug 2016 10:25:59 -0400 Original-Received: from 84.94.185.246.cable.012.net.il ([84.94.185.246]:2373 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_128_CBC_SHA1:128) (Exim 4.82) (envelope-from ) id 1baOGc-0003JR-3p; Thu, 18 Aug 2016 10:25:58 -0400 In-reply-to: (message from Stefan Monnier on Wed, 10 Aug 2016 12:11:21 -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:206648 Archived-At: > From: Stefan Monnier > Cc: emacs-devel@gnu.org > Date: Wed, 10 Aug 2016 12:11:21 -0400 > > >> > except that the call to before-change-functions in some cases does not > >> > precede the first modification of the series. IOW, by the time the > >> > hook is called, some modifications were already done. > >> Sounds like a bug. > > I'm not convinced it's a bug. > > before-change-functions should be called *before* a > change occurs. If there is a call to b-c-f before the first > modification, and then another call before the second modification in > that series, then it's OK (assuming the BEG/END values are sufficiently > large in each call to cover the changes that occur before the next call). > > But if a change occurs without having been "announced" by an earlier > b-c-f then it's a bug. I've reviewed all the places where we may not call the before- and the after-change hooks. They are just a few. One questionable place is insert-file-contents: it deliberately never calls the before-change-functions when it deletes portions of the text, only when it inserts text. I don't really understand the reasons behind your insisting on before-change-functions being called before any changes in this case, but maybe a simple way out would be to announce at the beginning of the function that the entire range between point-min and point-max is about to be changed, when REPLACE is non-nil. Another place where before-change-functions is not called, but after-change-functions are is set-buffer-multibyte. Moreover, if the function is called with a nil argument, we don't call after-change-functions as well. Is that supposed to be handled as a buffer change or not? In the low levels of encoding and decoding routines, we sometimes call the hooks and sometimes don't, depending on what is the source and the destination of the en/decoding, and whether there are pre-write or pre-write conversions. But the buffer in question is a temporary conversion buffer, so do we care? In message_dolog, which is called by any code which logs a message in *Messages*, we never call the before-change-functions for the *Messages* buffer, but we do call the after-change-functions for it. Problem or not? That's all I found. > >> In any case, my point is that the doc should still say "before any > >> modification" because that's really what the code *should* do. We could > >> add a blurb in the doc saying that the before and after hooks may not be > >> properly paired (neither in number of calls nor in the specific value of > >> BEG/END), but we should still claim that they're both called for any and > >> all modifications > > Which is inaccurate when modifications are done in several separate > > parts, and you already agreed it's okay to call the hooks only once. > > So "for any and all modifications" is bound to draw fire from people > > who take that at face value. > > They're free to misunderstand it, I'm fine with it. Then what is the value of such a misleading documentation? The current text says: This variable holds a list of functions to call when Emacs is about to modify a buffer. It intentionally refrains from saying "any and all modifications", and instead tries to be more vague. Do you still think this is not good enough? Because if you do, I don't see how we can say anything more accurate and yet avoid misleading the reader.