From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Noam Postavsky Newsgroups: gmane.emacs.devel Subject: Re: Unbalanced change hooks (part 2) Date: Sun, 31 Jul 2016 15:20:31 -0400 Message-ID: References: <20160731121642.GB2205@acm.fritz.box> <83a8gxq288.fsf@gnu.org> <20160731172804.GD2205@acm.fritz.box> <834m75ptij.fsf@gnu.org> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 X-Trace: blaine.gmane.org 1469992895 13587 80.91.229.8 (31 Jul 2016 19:21:35 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Sun, 31 Jul 2016 19:21:35 +0000 (UTC) Cc: ofv@wanadoo.es, Alan Mackenzie , Richard Copley , Emacs developers To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sun Jul 31 21:21:19 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 1bTwIY-0003SQ-S1 for ged-emacs-devel@m.gmane.org; Sun, 31 Jul 2016 21:21:19 +0200 Original-Received: from localhost ([::1]:40579 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bTwIV-0001dD-1H for ged-emacs-devel@m.gmane.org; Sun, 31 Jul 2016 15:21:15 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:38836) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bTwHt-0001bO-88 for emacs-devel@gnu.org; Sun, 31 Jul 2016 15:20:38 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1bTwHr-0007ST-7q for emacs-devel@gnu.org; Sun, 31 Jul 2016 15:20:36 -0400 Original-Received: from mail-oi0-x229.google.com ([2607:f8b0:4003:c06::229]:36327) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bTwHo-0007Rp-G3; Sun, 31 Jul 2016 15:20:32 -0400 Original-Received: by mail-oi0-x229.google.com with SMTP id w18so168159846oiw.3; Sun, 31 Jul 2016 12:20:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=myDgH6sqw+bKaVAzSW+hP9voqMQiSyFaSg9nlySVezE=; b=ddRuWO0pz+BJ8DI++EonbM0b7pMgGPhSEnF+Dkvw8fIfMyb7mahFq5d3CRneqzJa5K 6Y8QSBadPYmlmNwbjB1DcP2viogb1pMXzY0iRs6CJRar2KglEsv782PgjMOy9Yps12r5 UeBE8cU4c6dMMAuizYoMnO7lkLaQzejcMzMLaQ2lFOtdiLdI5GU8BMPUyrEBkI3X6xAb D1NG2xZfLq0VGSKyPxWQ9J/s5aWsf4DMvFbBZ5n2Wbt1twOBjxJgIM1zlOW1I4znUkyW o+4Dk/Hs4Cr7cIn/FrAxV7IOCRMkrsyUGhuVBv3fFVfVhKNh3BGq2tbKpL5EpadDBHeT VO9g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=myDgH6sqw+bKaVAzSW+hP9voqMQiSyFaSg9nlySVezE=; b=W9ShzjM67Xyd9JDhHV3EdX5o47IdzBywF3EvQcrD/z/6l5jLQZrDfF90W7Bnv/eoPF p8Gknkv/bSw6KqJos3x7AgPnrRCwzBu0xfRqxEcwi7M+5GWU7cgRpjwDJY1yoO57+vGe oRde+R4z2OEdyAe0rziniHCkHz2uKSt5GOUeA/AehIUaMaQjK07kjFCqjagMMQXxeyPm XjYQzDuqGj8gtk5dYpNQX28ZKvG9X0Pkqmy2HazmmGS7rNpiZQ2MTUbHDZxcPhgDtjPz e6xeFCIaatjrWeCmeFp7Lv4xduCyVvCbr+4fGgWGnkaabLLVuSgQt0l/elbgd25ArPw/ ex0A== X-Gm-Message-State: AEkoouvaW3K8mH4Hru8ZEImH9h1C235m3XMwFWwkcuulHlgKgT4HmkLEZ5je3hLcSGJde6V8J8OMj2MvZwSrcw== X-Received: by 10.202.86.15 with SMTP id k15mr28165727oib.178.1469992832086; Sun, 31 Jul 2016 12:20:32 -0700 (PDT) Original-Received: by 10.157.7.161 with HTTP; Sun, 31 Jul 2016 12:20:31 -0700 (PDT) In-Reply-To: <834m75ptij.fsf@gnu.org> X-Google-Sender-Auth: fNfXUks7BQ4O66rhoyudjRJU4oA X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 2607:f8b0:4003:c06::229 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:206283 Archived-At: On Sun, Jul 31, 2016 at 2:11 PM, Eli Zaretskii wrote: >> 2. Where a call to signal_buffer_change is within an "if (prepare) ..." >> construct, move it to after that construct, so that >> >> if (prepare) >> { >> prepare_to_modify_buffer (...); >> signal_after_change (...); >> } >> >> would become >> >> if (prepare) >> prepare_to_modify_buffer (...); >> signal_after_change (...); > > See, that's the part that scares me. You are proposing to run code > where we didn't run it before. Did you look at what > signal_after_change does? It doesn't just call > after-change-functions, it does much more. Doesn't look like that much more to me. In addtion to after-change-functions, it also calls overlay and text property modification hooks. I don't see anything else.