From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Stefan Monnier Newsgroups: gmane.emacs.devel Subject: Re: Unbalanced change hooks (part 2) [Documentation fix still remaining] Date: Sun, 28 Aug 2016 20:09:25 -0400 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> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: blaine.gmane.org 1472429246 3159 195.159.176.226 (29 Aug 2016 00:07:26 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Mon, 29 Aug 2016 00:07:26 +0000 (UTC) User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.1.50 (gnu/linux) To: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Aug 29 02:07:23 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 1beA6k-0000PL-BT for ged-emacs-devel@m.gmane.org; Mon, 29 Aug 2016 02:07:22 +0200 Original-Received: from localhost ([::1]:41274 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1beA6h-0008QQ-Tb for ged-emacs-devel@m.gmane.org; Sun, 28 Aug 2016 20:07:19 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:35156) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1beA66-0008QJ-OY for emacs-devel@gnu.org; Sun, 28 Aug 2016 20:06:43 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1beA62-0002sj-Hn for emacs-devel@gnu.org; Sun, 28 Aug 2016 20:06:41 -0400 Original-Received: from [195.159.176.226] (port=58030 helo=blaine.gmane.org) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1beA62-0002rV-B4 for emacs-devel@gnu.org; Sun, 28 Aug 2016 20:06:38 -0400 Original-Received: from list by blaine.gmane.org with local (Exim 4.84_2) (envelope-from ) id 1beA5u-0004Gk-8w for emacs-devel@gnu.org; Mon, 29 Aug 2016 02:06:30 +0200 X-Injected-Via-Gmane: http://gmane.org/ Original-Lines: 42 Original-X-Complaints-To: usenet@blaine.gmane.org Cancel-Lock: sha1:8FxgHpRtZuOHSymHAERtmgMGJL4= X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 195.159.176.226 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:206850 Archived-At: > 1) b-c-f isn't currently balanced with a-c-f in the insdel.c implementation There's no guarantee that it be balanced, indeed. > 2) b-c-f isn't currently guaranteed to be called at all before any given > call to a-c-f (e.g., the C-x C-f case) It is guaranteed, modulo bugs (the insert-file-contents (with replace) case). > 2) the documentation suggests that a-c-f and b-c-f are balanced I don't see where in the documentation it suggests it. > 3) many people, Alan and me included, were under the impression that b-c-f > and a-c-f were balanced and wrote code accordingly Ah, so you too have code which makes this assumption. Could you point to it, explaining what it does and why it makes this assumption, so we have a better picture of why it could be useful? > AIUI, Eli's position is that the current behavior should not change at all, > because making changes at this level is too risky. I don't think he said "at all", but just that it's tricky to make such changes, so they had better be backed by really good reasons. > Your position is that #2 is a bug, but #1 is not, and the > documentation needs to change. Almost: I don't see the need to change the doc because I don't see where it misleads. > So what do you propose doing? Upthread, I explained why I think that fixing > both #1 and #2 is pretty low-risk. The problem is that changing the code w.r.t b/a-c-f might cause *other* changes. Clearly making them perfectly balanced and paired should not *in itself* introduce any bugs: the bugs we're afraid of are the accompanying unintended changes. Stefan