From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Daniel Colascione Newsgroups: gmane.emacs.devel Subject: Re: Unbalanced change hooks (part 2) [Documentation fix still remaining] Date: Mon, 29 Aug 2016 08:30:21 -0700 Message-ID: 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> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-Trace: blaine.gmane.org 1472484645 11099 195.159.176.226 (29 Aug 2016 15:30:45 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Mon, 29 Aug 2016 15:30:45 +0000 (UTC) User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 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 Mon Aug 29 17:30:41 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 1beOWF-0002Gj-Ia for ged-emacs-devel@m.gmane.org; Mon, 29 Aug 2016 17:30:39 +0200 Original-Received: from localhost ([::1]:44071 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1beOWD-00030z-3v for ged-emacs-devel@m.gmane.org; Mon, 29 Aug 2016 11:30:37 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:37748) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1beOW7-00030u-ET for emacs-devel@gnu.org; Mon, 29 Aug 2016 11:30:32 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1beOW4-0001pq-7f for emacs-devel@gnu.org; Mon, 29 Aug 2016 11:30:31 -0400 Original-Received: from dancol.org ([96.126.100.184]:34834) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1beOW3-0001pT-RZ; Mon, 29 Aug 2016 11:30:28 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=dancol.org; s=x; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:MIME-Version:Date:Message-ID:From:Cc:References:To:Subject; bh=F3OgH8DejKPoLwkBAJaGe/yF58UwJvzUU8r3di2cMJ0=; b=jHuQtukQRH0ZV2DqkpdesIY/sUBD43Wdy+X7SiMDi8oiar2P4SQZHXfG9cRGXFrdZGJFdTTBKxJoWJ/35oArMbqbbWDi17DLdZTz8epoTxiQZqiEs3xYVVw8bbskgtcLgUl7jOLzSrbLqFJciKE70iaeJ6Wb2WZDUwD7brTL64khP8xw9wFtXbyU5FV2P/cRkAdYItzqYVklKtRcm3rb/QiiNJLwifP5p62H1k7YMsukCirXP598ykjisBGIDzQLutNn92X5NECMknFGYvJp9gNDPBqi1FfAnPmIi/ys0gKTDiJ0PmT0EsswBehd6G1iVuODlpIG0REWqdPsMkN67w==; Original-Received: from c-73-97-199-232.hsd1.wa.comcast.net ([73.97.199.232] helo=[192.168.1.173]) by dancol.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.84_2) (envelope-from ) id 1beOW1-0005Cy-NF; Mon, 29 Aug 2016 08:30:25 -0700 In-Reply-To: <83inujbpek.fsf@gnu.org> X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 96.126.100.184 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:206876 Archived-At: On 08/29/2016 07:50 AM, Eli Zaretskii wrote: >> 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. Just mark b-c-f deprecated. >> 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. It doesn't matter what a "change" means and entails. Whatever a "change" is, b-c-f and a-c-f use the same word for it, and I've already explained why it's natural to suppose symmetry between these hooks. In order for b-c-f and a-c-f to be asymmetric, the definition of the word "change" needs to somehow change. Do you really not understand why many people would find the current behavior surprising? You have at least *three* people independently annoyed by it: Alan, Phillip Lord, and me. >> 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. The current implementation is buggy. Even Stefan agrees that it currently contains bona fide bugs (the file visit case). These bugs produce difficult-to-diagnose user bugs reports. that have generated real bug reports. The current implementation does not serve the needs of its users. I mean, you could just declare the current implementation correct and point to workarounds as evidence of the fact --- but that's like declaring a drain unclogged by definition and pointing to the plunger as evidence. >> 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. The modern software engineering approach to preventing regressions is test automation. Insisting on adding a test as part of the change is reasonable. Forbidding all change, no matter how carefully done, is not. > Never again. The surest way to make sure a computer doesn't do anything wrong is to turn it off.