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: Wed, 10 Aug 2016 18:57:35 +0000 Message-ID: <20160810185735.GD3413@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> <20160810161821.GB3413@acm.fritz.box> <83wpjofttf.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 1470855536 23543 195.159.176.226 (10 Aug 2016 18:58:56 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Wed, 10 Aug 2016 18:58:56 +0000 (UTC) User-Agent: Mutt/1.5.24 (2015-08-30) Cc: monnier@iro.umontreal.ca, emacs-devel@gnu.org To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Wed Aug 10 20:58:51 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 1bXYiH-0005vF-Ru for ged-emacs-devel@m.gmane.org; Wed, 10 Aug 2016 20:58:49 +0200 Original-Received: from localhost ([::1]:43282 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bXYiE-0004ua-SX for ged-emacs-devel@m.gmane.org; Wed, 10 Aug 2016 14:58:46 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:36192) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bXYhg-0004uJ-1T for emacs-devel@gnu.org; Wed, 10 Aug 2016 14:58:13 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1bXYhc-0006cY-To for emacs-devel@gnu.org; Wed, 10 Aug 2016 14:58:12 -0400 Original-Received: from mail.muc.de ([193.149.48.3]:45809) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bXYhc-0006cA-Ji for emacs-devel@gnu.org; Wed, 10 Aug 2016 14:58:08 -0400 Original-Received: (qmail 34339 invoked by uid 3782); 10 Aug 2016 18:58:06 -0000 Original-Received: from acm.muc.de (p548C65E5.dip0.t-ipconnect.de [84.140.101.229]) by colin.muc.de (tmda-ofmipd) with ESMTP; Wed, 10 Aug 2016 20:58:05 +0200 Original-Received: (qmail 4267 invoked by uid 1000); 10 Aug 2016 18:57:35 -0000 Content-Disposition: inline In-Reply-To: <83wpjofttf.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:206549 Archived-At: Hello, Eli. On Wed, Aug 10, 2016 at 07:54:36PM +0300, Eli Zaretskii wrote: > > Date: Wed, 10 Aug 2016 16:18:21 +0000 > > Cc: Stefan Monnier , emacs-devel@gnu.org > > From: Alan Mackenzie > > > > Then the old text was right: it's called before ANY modification. > > > Convince Alan, and I will change it back. > > For what it's worth, I don't like the vagueness of the doc as it > > currently is, and I wouldn't be against changing it back _FOR 25.1_ > > We've got a bug, but it's not urgent enough to have to be fixed for > > 25.1. > I made further adjustments to the text. It is now closer to what it > was before, but I don't feel it's wise for it to be as definitive as > it was originally, as someone will surely interpret that too literally > and file another bug report, or design a feature based on incorrect > assumptions. ######################################################################### Do @emph{not} expect the before-change hooks and the after-change 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 assumption that Lisp programs will use either before- or the after-change hooks, but not both, and the boundaries of the region where the changes happen might include more than just the actual changed text, or even lump together several changes done piecemeal. ######################################################################### I don't like that text at all. For what it's worth, I find it objectionable in the extreme. It's not even true. One can (indeed, often MUST) expect b-c-f and a-c-f to work in pairs, and it is only on the rarest of occasions that they do not - it's taken ~10 years for this bug to show up. Editing text involves deletions and insertions. Deletions can be known only in before-change-functions, insertions only in after-change-functions. What you are proposing is partitioning Elisp programs into those that know only deletions, and those that know only insertions. Any program using syntax-ppss would by that principle be debarred from using a-c-f, since s-ppss uses b-c-f. This is absurd. If you insist on this strand of documentation (which is surely controversial enough not to be allowed into Emacs 25.1 at this late stage) then please provide a function called something like `old-text' which an after-change function could use to recover deleted text. CC Mode absolutely requires to know both deletions and insertions for its proper functioning. Nobody has yet demonstrated that it can work properly knowing only insertions, despite Stefan loudly and repeatedly proclaiming it can. Must I look forward to a bug report from some busybody moaning that CC Mode "illegitimately" uses both change hooks? OK, I've complained enough, so I ought to suggest something positive. Here is what I would put into the documentation in place of that paragraph. I think it is accurate and reasonable. ######################################################################### Normally the before-change-functions and the after-change-functions hooks are called in balanced pairs around each buffer change, enabling state to be determined in a before-change function and used in an after-change function. However on rare occasions, before-change-functions is not called before a buffer change and after-change-functions is thus called twice in succession. Your program should be ready to deal with such an occurrence. ######################################################################### [ .... ] > Thanks. -- Alan Mackenzie (Nuremberg, Germany).