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 19:20:16 +0300 Message-ID: <83eg57bl8f.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> 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 1472487648 13255 195.159.176.226 (29 Aug 2016 16:20:48 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Mon, 29 Aug 2016 16:20:48 +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 18:20:42 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 1bePIc-0002e8-Bk for ged-emacs-devel@m.gmane.org; Mon, 29 Aug 2016 18:20:38 +0200 Original-Received: from localhost ([::1]:44733 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bePIa-00081j-09 for ged-emacs-devel@m.gmane.org; Mon, 29 Aug 2016 12:20:36 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:56808) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bePIQ-00080V-9y for emacs-devel@gnu.org; Mon, 29 Aug 2016 12:20:30 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1bePIL-000624-Ut for emacs-devel@gnu.org; Mon, 29 Aug 2016 12:20:26 -0400 Original-Received: from fencepost.gnu.org ([2001:4830:134:3::e]:37457) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bePIL-00061r-RC; Mon, 29 Aug 2016 12:20:21 -0400 Original-Received: from 84.94.185.246.cable.012.net.il ([84.94.185.246]:1190 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_128_CBC_SHA1:128) (Exim 4.82) (envelope-from ) id 1bePIK-00031c-7T; Mon, 29 Aug 2016 12:20:21 -0400 In-reply-to: (message from Daniel Colascione on Mon, 29 Aug 2016 08:30:21 -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:206883 Archived-At: > Cc: monnier@iro.umontreal.ca, emacs-devel@gnu.org > From: Daniel Colascione > Date: Mon, 29 Aug 2016 08:30:21 -0700 > > >> 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. Of course, you have changed the subject. > 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. It doesn't matter what I understand or not, because that's not the issue at hand. We are talking about code that runs virtually unchanged for many years. Making significant changes in it needs a good reason. When such good reasons emerge, we can discuss whether they justify the risks. For now, the reasons presented do not. > The current implementation is buggy. Every piece of software is buggy. That doesn't mean it's useless or must be refactored the heck out of. > (the file visit case). These bugs produce difficult-to-diagnose user > bugs reports. that have generated real bug reports. Those bugs were fixed. > 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 not interested in an argument about correctness. That's not what this is about. You are changing the subject again. > > 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. No one have forbidden all change, and no one in their right minds will. Do you really not understand what the above is about? > > Never again. > > The surest way to make sure a computer doesn't do anything wrong is to > turn it off. If you aren't interested in it doing anything useful, sure. But I am, so these simple solutions are wrong for me (and for all the rest of Emacs users). Of course, if those absurd "arguments" are the only ones you have left, I guess this is EOD.