From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Alan Mackenzie Newsgroups: gmane.emacs.devel Subject: Unbalanced change hooks (part 2) Date: Sun, 31 Jul 2016 12:16:42 +0000 Message-ID: <20160731121642.GB2205@acm.fritz.box> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: blaine.gmane.org 1469967473 29404 80.91.229.8 (31 Jul 2016 12:17:53 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Sun, 31 Jul 2016 12:17:53 +0000 (UTC) User-Agent: Mutt/1.5.24 (2015-08-30) Cc: =?iso-8859-1?Q?=D3scar?= Fuentes , Richard Copley To: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sun Jul 31 14:17:39 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 1bTpgY-0007az-LY for ged-emacs-devel@m.gmane.org; Sun, 31 Jul 2016 14:17:38 +0200 Original-Received: from localhost ([::1]:39485 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bTpgU-0007UB-Ph for ged-emacs-devel@m.gmane.org; Sun, 31 Jul 2016 08:17:34 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:42929) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bTpgP-0007U5-5G for emacs-devel@gnu.org; Sun, 31 Jul 2016 08:17:30 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1bTpgL-0001h0-V7 for emacs-devel@gnu.org; Sun, 31 Jul 2016 08:17:29 -0400 Original-Received: from mail.muc.de ([193.149.48.3]:49037) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bTpgL-0001gn-LG for emacs-devel@gnu.org; Sun, 31 Jul 2016 08:17:25 -0400 Original-Received: (qmail 31012 invoked by uid 3782); 31 Jul 2016 12:17:23 -0000 Original-Received: from acm.muc.de (p548C7DF4.dip0.t-ipconnect.de [84.140.125.244]) by colin.muc.de (tmda-ofmipd) with ESMTP; Sun, 31 Jul 2016 14:17:21 +0200 Original-Received: (qmail 2835 invoked by uid 1000); 31 Jul 2016 12:16:42 -0000 Content-Disposition: inline X-Delivery-Agent: TMDA/1.1.12 (Macallan) X-Primary-Address: acm@muc.de X-detected-operating-system: by eggs.gnu.org: FreeBSD 9.x X-Received-From: 193.149.48.3 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:206264 Archived-At: Hello, Emacs. There are several functions in .../src/insdel.c which have a parameter `prepare'. The meaning of `prepare' is "direct the function to call prepare_to_modify_buffer" (YUCK!). Thus, whether or not before-change-functions is invoked is determined by the `prepare' parameter. The pertinent functions are insert_1_both, replace_range, del_range_1, del_range_byte, and del_range_both. These functions fall into two groups, the first two in group 1 and the rest in group 2. Those in group 2 always call signal_after_change, those in group 1 never do. There are invocations of group 2 functions with `prepare' false. This wrongly invokes after-change-functions without having invoked before-change-functions. All the invocations of group 1 functions I've checked so far balance a true `prepare' with an explicit call of signal_after_change. At the heart of the problem is the lack of coherence in prepare_to_modify_buffer. This function has no definite coherent function, the best description that can be given it being "perform some of the things which need doing before a buffer change". It is unclear which of these things is unwanted when `prepare' is set to false. The group 2 functions always invoke after-change-functions, so they must always invoke before-change-functions. In Finsert_file_contents there are instances of del_range_byte with `prepare' false. The spurious lack of the before-change-functions invocation fouls up CC Mode, causing bug #240[79]4. I propose that the call to signal_before_change should be removed from prepare_to_modify_buffer, and that it should be called explicitly from the places it is needed. This would allow bug #240[79]4 to be fixed. Comments? -- Alan Mackenzie (Nuremberg, Germany).