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: Fri, 02 Sep 2016 10:26:12 +0300 Message-ID: <83oa46ep9n.fsf@gnu.org> References: <83inv9hkjd.fsf@gnu.org> <83h9ashfgx.fsf@gnu.org> <831t1wharr.fsf@gnu.org> <20160810161821.GB3413@acm.fritz.box> <83wpjofttf.fsf@gnu.org> <20160810185735.GD3413@acm.fritz.box> <20160811112951.GA2154@acm.fritz.box> <7e1478b6-cf00-fcbf-8c24-43bdaa57e2b6@dancol.org> <415d1cca-f32c-624e-a4be-9aadcf8a0f17@dancol.org> <83inujbpek.fsf@gnu.org> <8f54985c-09f9-ad1f-6132-43e7c04fc2a9@lanl.gov> Reply-To: Eli Zaretskii NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Trace: blaine.gmane.org 1472801219 25012 195.159.176.226 (2 Sep 2016 07:26:59 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Fri, 2 Sep 2016 07:26:59 +0000 (UTC) Cc: dancol@dancol.org, monnier@iro.umontreal.ca, emacs-devel@gnu.org To: Davis Herring Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Fri Sep 02 09: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 1bfisC-0005OT-BF for ged-emacs-devel@m.gmane.org; Fri, 02 Sep 2016 09:26:48 +0200 Original-Received: from localhost ([::1]:40668 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bfisA-00049V-1Z for ged-emacs-devel@m.gmane.org; Fri, 02 Sep 2016 03:26:46 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:40397) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bfirf-00049E-Ob for emacs-devel@gnu.org; Fri, 02 Sep 2016 03:26:16 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1bfirb-0004RV-H5 for emacs-devel@gnu.org; Fri, 02 Sep 2016 03:26:14 -0400 Original-Received: from fencepost.gnu.org ([2001:4830:134:3::e]:49334) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bfirb-0004RN-Dd; Fri, 02 Sep 2016 03:26:11 -0400 Original-Received: from 84.94.185.246.cable.012.net.il ([84.94.185.246]:2039 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_128_CBC_SHA1:128) (Exim 4.82) (envelope-from ) id 1bfirZ-0007Cp-B4; Fri, 02 Sep 2016 03:26:09 -0400 In-reply-to: <8f54985c-09f9-ad1f-6132-43e7c04fc2a9@lanl.gov> (message from Davis Herring on Thu, 1 Sep 2016 15:25:01 -0600) 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:207114 Archived-At: > Cc: emacs-devel@gnu.org > From: Davis Herring > Date: Thu, 1 Sep 2016 15:25:01 -0600 > > > This is a naïve interpretation of what a "change" means and entails. > > In reality, some changes are done with a single call to an insdel > > function, while others need multiple calls that delete and insert text > > piecemeal. Thus the need to call the hooks before and after each > > insdel call only sometimes. > > Indeed, no one knows what we mean by "change". To make progress, we > must introduce a formal definition for it I envision that to be a very hard job, given the complexity of some changes and the fact that at least some of them are not considered "changes" for this purpose (see past discussions for the details). Moreover, doing so was never the Emacs way. Emacs always tries to do things the naturally expected way, so that these issues don't arise. If we need to go into such fine details and argue about formal definitions of a "buffer change", that is a clear sign that something is wrong and needs to be fixed, in a way that makes the "natural" definition be implicitly correct, because the effect is as expected by Lisp programmers. Therefore, I think that spending any effort on making the manual text more formally correct will be a wasted effort. As long as the implementation remains as it is now, the problem with its accurate description in the manual will persist, and no small patches to the code will resolve it completely. > I therefore propose approach #3 as the minimal change to the current > implementation that provides a behavioral guarantee worth documenting. I don't think this issue can be attacked using only abstract high-level considerations and resolved by solutions that are logically complete, but may not be helpful in practice. Instead, the use cases we want to support, both wrt the implementation of complex changes we have in Emacs and wrt the users of these hooks, should be collected and analyzed. Then the best approach that accommodates these needs (including perhaps any future needs we can envision) should be designed and implemented. My gut feeling is that the correct model which will emerge from this will be very different from what we have now. Thanks.