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:46:10 +0300 Message-ID: <83pooqmch9.fsf@gnu.org> References: <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> <8cea494d-33e0-0a7d-2bd0-c8bfb9f597aa@dancol.org> <8760qie4f4.fsf@russet.org.uk> <8337lmntkk.fsf@gnu.org> <5736d945-dff5-e03a-499e-ce2054815ea6@dancol.org> Reply-To: Eli Zaretskii NNTP-Posting-Host: blaine.gmane.org X-Trace: blaine.gmane.org 1472575626 10192 195.159.176.226 (30 Aug 2016 16:47:06 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Tue, 30 Aug 2016 16:47:06 +0000 (UTC) Cc: emacs-devel@gnu.org, monnier@IRO.UMontreal.CA, phillip.lord@russet.org.uk To: Daniel Colascione Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Aug 30 18:47:02 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 1bemBh-00027E-BB for ged-emacs-devel@m.gmane.org; Tue, 30 Aug 2016 18:47:01 +0200 Original-Received: from localhost ([::1]:50190 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bemBf-0005Vh-0j for ged-emacs-devel@m.gmane.org; Tue, 30 Aug 2016 12:46:59 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:60324) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bemB8-0005Vb-2c for emacs-devel@gnu.org; Tue, 30 Aug 2016 12:46:27 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1bemB4-00088l-2G for emacs-devel@gnu.org; Tue, 30 Aug 2016 12:46:26 -0400 Original-Received: from fencepost.gnu.org ([2001:4830:134:3::e]:57202) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bemB3-000882-V0; Tue, 30 Aug 2016 12:46:21 -0400 Original-Received: from 84.94.185.246.cable.012.net.il ([84.94.185.246]:1766 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_128_CBC_SHA1:128) (Exim 4.82) (envelope-from ) id 1bemB1-0006xq-RG; Tue, 30 Aug 2016 12:46:20 -0400 In-reply-to: <5736d945-dff5-e03a-499e-ce2054815ea6@dancol.org> (message from Daniel Colascione on Tue, 30 Aug 2016 09:22: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:206961 Archived-At: > Cc: monnier@IRO.UMontreal.CA, emacs-devel@gnu.org > From: Daniel Colascione > Date: Tue, 30 Aug 2016 09:22:21 -0700 > > > My response is that we should not do it until we have decent test > > coverage of the insdel functionality. I simply don't believe in our > > ability to avoid breakage in this core functionality unless we have > > good test coverage. Been there, done that, have bruises to prove it. > > More tests in general would be nice. I have no objection to requiring > test coverage for insdel before making major changes; my objection is to > a blanket ban on changes even *with* test coverage. I was the under the > impression that your preference was for the latter model, but IIUC, you > actually hold the former position. I'm simply disillusioned wrt to possibility of any significant progress in having tests in these areas. Almost all of our tests are in application areas, while the functions in src/ remain almost completely uncovered. I have no reason to believe this will change any time soon (but I will be happy to be mistaken, of course). That is why I could have sent ambiguous messages in this regard. (And it's not only insdel that will be affected, because signal_before_change and signal_after_change also affect the various caches we maintain for a buffer, its markers, text properties and overlays, etc. All of which will have to be covered by tests, before we can consider serious changes in this area.)