From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Alan Mackenzie Newsgroups: gmane.emacs.devel Subject: Re: Unbalanced change hooks (part 2) [Documentation fix still remaining] Date: Fri, 19 Aug 2016 08:45:26 +0000 Message-ID: <20160819084526.GA1971@acm.fritz.box> References: <83tweugeu9.fsf@gnu.org> <20160809163814.GD4893@acm.fritz.box> <83inv9hkjd.fsf@gnu.org> <83h9ashfgx.fsf@gnu.org> <831t1wharr.fsf@gnu.org> <83mvkaduh0.fsf@gnu.org> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: blaine.gmane.org 1471596381 30185 195.159.176.226 (19 Aug 2016 08:46:21 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Fri, 19 Aug 2016 08:46:21 +0000 (UTC) User-Agent: Mutt/1.5.24 (2015-08-30) Cc: Stefan Monnier , emacs-devel@gnu.org To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Fri Aug 19 10:46:15 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 1bafRP-0007WE-5m for ged-emacs-devel@m.gmane.org; Fri, 19 Aug 2016 10:46:15 +0200 Original-Received: from localhost ([::1]:56149 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bafRM-0008Tq-6O for ged-emacs-devel@m.gmane.org; Fri, 19 Aug 2016 04:46:12 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:33271) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bafRF-0008St-KD for emacs-devel@gnu.org; Fri, 19 Aug 2016 04:46:07 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1bafR9-0002ka-U6 for emacs-devel@gnu.org; Fri, 19 Aug 2016 04:46:04 -0400 Original-Received: from mail.muc.de ([193.149.48.3]:56842) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bafR9-0002kR-Ju for emacs-devel@gnu.org; Fri, 19 Aug 2016 04:45:59 -0400 Original-Received: (qmail 23345 invoked by uid 3782); 19 Aug 2016 08:45:56 -0000 Original-Received: from acm.muc.de (p548C6379.dip0.t-ipconnect.de [84.140.99.121]) by colin.muc.de (tmda-ofmipd) with ESMTP; Fri, 19 Aug 2016 10:45:55 +0200 Original-Received: (qmail 2801 invoked by uid 1000); 19 Aug 2016 08:45:26 -0000 Content-Disposition: inline In-Reply-To: <83mvkaduh0.fsf@gnu.org> X-Delivery-Agent: TMDA/1.1.12 (Macallan) X-Primary-Address: acm@muc.de X-detected-operating-system: by eggs.gnu.org: FreeBSD 9.x X-Received-From: 193.149.48.3 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:206660 Archived-At: Hello, Eli. On Thu, Aug 18, 2016 at 05:26:03PM +0300, Eli Zaretskii wrote: > > 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. Thanks! > 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. That might create difficulties for CC Mode. CC Mode now recognises when b-c-f isn't called at all, but isn't, as far as I've thought it through, prepared to deal with b-c-f with inaccurate arguments. > 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? Possibly not - only the lowest levels of code would notice any difference. > 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? "Change Hooks" in the Elisp manual states that b-c-f and a-c-f are not called for the *Messages* buffer. So I would say calling a-c-f here is a bug. > 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. Somebody wanting to use b-c-f and reading that text is likely to conclude that b-c-f is called for _every_ change, just as I did ~10 years ago. > 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. How can accurate documentation mislead? -- Alan Mackenzie (Nuremberg, Germany).