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: Mon, 29 Aug 2016 17:50:11 +0300 Message-ID: <83inujbpek.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> 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 1472482240 19086 195.159.176.226 (29 Aug 2016 14:50:40 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Mon, 29 Aug 2016 14:50:40 +0000 (UTC) Cc: monnier@iro.umontreal.ca, emacs-devel@gnu.org To: Daniel Colascione Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Aug 29 16:50:35 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 1beNtR-0004Uu-5m for ged-emacs-devel@m.gmane.org; Mon, 29 Aug 2016 16:50:33 +0200 Original-Received: from localhost ([::1]:43930 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1beNtO-0004w5-QL for ged-emacs-devel@m.gmane.org; Mon, 29 Aug 2016 10:50:30 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:56557) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1beNtI-0004vy-Ci for emacs-devel@gnu.org; Mon, 29 Aug 2016 10:50:25 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1beNtD-0002FU-Bu for emacs-devel@gnu.org; Mon, 29 Aug 2016 10:50:23 -0400 Original-Received: from fencepost.gnu.org ([2001:4830:134:3::e]:36070) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1beNtD-0002FQ-8Y; Mon, 29 Aug 2016 10:50:19 -0400 Original-Received: from 84.94.185.246.cable.012.net.il ([84.94.185.246]:4302 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_128_CBC_SHA1:128) (Exim 4.82) (envelope-from ) id 1beNtB-0004Pq-Ai; Mon, 29 Aug 2016 10:50:18 -0400 In-reply-to: (message from Daniel Colascione on Sun, 28 Aug 2016 20:18:32 -0700) 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:206872 Archived-At: > From: Daniel Colascione > Date: Sun, 28 Aug 2016 20:18:32 -0700 > > Please trust me that the documentation misleads. You are welcome to suggest more accurate wording that describes the current implementation. > b-c-f and a-c-f are symmetric in name and signature. b-c-f is documented as "List of functions to call before each text change." a-c-f is documented as "List of functions to call after each text change." The elisp manual documentation is similarly symmetric. This symmetry produces an expectation that the behavior is symmetric, and this expectation is reinforced by how the observed behavior is almost always symmetric in practice. Symmetric behavior here is also what intuitively makes sense. 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. Your bell analogy has the same issue: internally, the "chime" is in fact a complex array of transitions and changes, not an atomic effect. By treating it as an atomic unit, you actually uphold the view taken by the current implementation, which attempts to minimize the number of hook calls per change. > Sure, I guess you could argue that current Emacs behavior is consistent with the manual, but it's not what anyone would reasonably expect, and the current behavior is surprising even to people who have been writing elisp for a long time. Surprising or not, the existing implementation is in use for many years, and until now no complaints were presented about it. And even now we have a single complaint from a single use case of a single package (which meanwhile fixed the problem without any core changes). Which is ample evidence that the existing implementation does a good job after all. > I'm confident that with enough review, the core code could be changed to make b-c-f and a-c-f symmetric without causing weird bugs elsewhere. The necessary refactoring will probably make the logic cleaner as well. > > Of course there's a risk that changing b-c-f will itself produce weird side effects, but I have a hard time seeing how any code could actually depend on the current surprising behavior. That's exactly the nonchalant attitude towards changes in core that explains why, after 30-odd years of development, which should have given us an asymptotically more and more stable Emacs, we still succeed quite regularly to break core code and basic features, while "confidently" relying on our mythical abilities to refactor correctly without any serious testing coverage. Never again.