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: Tue, 30 Aug 2016 19:06:35 +0300 Message-ID: <831t16nsvo.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> <871t16e476.fsf@russet.org.uk> Reply-To: Eli Zaretskii NNTP-Posting-Host: blaine.gmane.org X-Trace: blaine.gmane.org 1472573275 30588 195.159.176.226 (30 Aug 2016 16:07:55 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Tue, 30 Aug 2016 16:07:55 +0000 (UTC) Cc: dancol@dancol.org, monnier@iro.umontreal.ca, emacs-devel@gnu.org To: phillip.lord@russet.org.uk (Phillip Lord) Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Aug 30 18:07:47 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 1belZj-0007GC-4r for ged-emacs-devel@m.gmane.org; Tue, 30 Aug 2016 18:07:47 +0200 Original-Received: from localhost ([::1]:49971 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1belZg-0001ry-On for ged-emacs-devel@m.gmane.org; Tue, 30 Aug 2016 12:07:44 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:47077) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1belYh-0001og-Ie for emacs-devel@gnu.org; Tue, 30 Aug 2016 12:06:44 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1belYd-0007Fa-AR for emacs-devel@gnu.org; Tue, 30 Aug 2016 12:06:42 -0400 Original-Received: from fencepost.gnu.org ([2001:4830:134:3::e]:56275) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1belYd-0007FW-6k; Tue, 30 Aug 2016 12:06:39 -0400 Original-Received: from 84.94.185.246.cable.012.net.il ([84.94.185.246]:1743 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_128_CBC_SHA1:128) (Exim 4.82) (envelope-from ) id 1belYc-0004gv-Ao; Tue, 30 Aug 2016 12:06:38 -0400 In-reply-to: <871t16e476.fsf@russet.org.uk> (phillip.lord@russet.org.uk) 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:206952 Archived-At: > From: phillip.lord@russet.org.uk (Phillip Lord) > Cc: Daniel Colascione , monnier@iro.umontreal.ca, emacs-devel@gnu.org > Date: Tue, 30 Aug 2016 15:12:13 +0100 > > > Surprising or not, the existing implementation is in use for many > > years, and until now no complaints were presented about it. > > Actually, it caused me significant issues several years ago, and I would > have prefered that the hooks were balanced. Me too, believe it or not. But this is not about our preferences. This is about the tough choices we must make when faced with the current situation, where this code was working for many years, we have a very small number of people who even understand the intricacies of the implementation, and users certainly don't expect to see Emacs 26 have bugs in basic text handling in buffers. IOW, we need to find the lesser evil. > > 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. > > No, I don't think it is. It might be evidence that people know to seek > alternative solutions instead of using b-c-f and a-c-f. Fine with me. I indeed prefer that in the current situation any bugs this could cause be fixed or worked around in the packages that are hit by them. As long as these problems are rare and far between, that is better than risking to break insdel and its callers, which could be virtually anywhere. If someone refactors insdel to introduce some significant new feature, then instability can be justified. But otherwise, it sounds nuts to me to risk that, given the rarity of the problems and the ability of the packages to work around them. Especially, as we have no way whatsoever of verifying the changes by tests. > > 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. > > Can I deliberately misinterpret this as saying that you think that the > changes would be fine so long as we add lots of tests at the same time? Not "at the same time", but "as a prerequisite" for any serious consideration of such changes. IOW, I want to see the tests first, decide whether I like their degree of coverage, and only then I will be prepared to _talk_ about any changes in this area. And the first step in that talk will have to be someone presenting a rather complete design of the changes, including an analysis of the current callers and how each one (or each class) of them will work under the new design.