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 09:26:38 -0700 Message-ID: <5ee6ff4a-2d58-82f1-8e83-479c62f0b729@dancol.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> <83eg57bl8f.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 1472488026 31816 195.159.176.226 (29 Aug 2016 16:27:06 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Mon, 29 Aug 2016 16:27:06 +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 18:27:01 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 1bePOm-0007kU-O5 for ged-emacs-devel@m.gmane.org; Mon, 29 Aug 2016 18:27:01 +0200 Original-Received: from localhost ([::1]:44750 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bePOk-0002KC-Ct for ged-emacs-devel@m.gmane.org; Mon, 29 Aug 2016 12:26:58 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:58592) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bePOc-0002K7-OJ for emacs-devel@gnu.org; Mon, 29 Aug 2016 12:26:51 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1bePOX-0007iZ-MW for emacs-devel@gnu.org; Mon, 29 Aug 2016 12:26:49 -0400 Original-Received: from dancol.org ([96.126.100.184]:35412) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bePOX-0007iT-DC; Mon, 29 Aug 2016 12:26:45 -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=vvOlGqphHirFfXDlqla+uuSlrtToGMl35GbTnYxj7F4=; b=RvChY+wlzmkD77NLTGtIoUO0DTXCewgDMJwj/rYWqtf7neEljEpSADka4agiofIPQJbO1LlIeP+eZwPRmwkh+28JkOrmhKiBs3TzRf7OgcHSGxqqXp9Rr2p0BeOqVVN83dwcf1ZbkzeCiBpXKCTr5OXlUGr5b2fg8kMy6ADsiM0WrUB0FUu7v9UV7NBdsoNXmYesoSdHlJbIUW/m1x2YJjiYgVRTDDEKaol+2VUNsiiuRbYVomTK0JKx8qc3YQHMa1xnvdpzjZMGeE0HznqsfMvkurheUdUjwQZdBzvBo3inwiMHmdfq7qAe5su4BfgTWJDXKlzG8E3v2EF64CTmvg==; 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 1bePOU-0005b7-JN; Mon, 29 Aug 2016 09:26:42 -0700 In-Reply-To: <83eg57bl8f.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:206886 Archived-At: On 08/29/2016 09:20 AM, Eli Zaretskii wrote: >> 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. What criteria are you using to determine whether a bug is sufficiently serious to fix? What would convince you that a change in this behavior is warranted?