From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED.blaine.gmane.org!not-for-mail From: Alan Mackenzie Newsgroups: gmane.emacs.devel Subject: Re: /* FIXME: Call signal_after_change! */ in callproc.c. Well, why not? Date: Sun, 5 Jan 2020 18:48:44 +0000 Message-ID: <20200105184844.GB4377@ACM> References: <20191221172324.GA8692@ACM> <83k16pzgzu.fsf@gnu.org> <20191221214751.GB8692@ACM> <83sglcxl1q.fsf@gnu.org> <20191224094724.GA3992@ACM> <837e2lwws9.fsf@gnu.org> <20191229133436.GA10699@ACM> <83eewhhqri.fsf@gnu.org> <20200104224730.GB4009@ACM> <83ftgtg43b.fsf@gnu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226"; logging-data="95820"; mail-complaints-to="usenet@blaine.gmane.org" User-Agent: Mutt/1.10.1 (2018-07-13) Cc: emacs-devel@gnu.org To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sun Jan 05 19:48:57 2020 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([209.51.188.17]) by blaine.gmane.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.89) (envelope-from ) id 1ioAxM-000OkY-Ps for ged-emacs-devel@m.gmane.org; Sun, 05 Jan 2020 19:48:56 +0100 Original-Received: from localhost ([::1]:44370 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1ioAxL-0005w7-2a for ged-emacs-devel@m.gmane.org; Sun, 05 Jan 2020 13:48:55 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:42622) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1ioAxF-0005w1-QG for emacs-devel@gnu.org; Sun, 05 Jan 2020 13:48:50 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ioAxE-0005Wk-Lc for emacs-devel@gnu.org; Sun, 05 Jan 2020 13:48:49 -0500 Original-Received: from colin.muc.de ([193.149.48.1]:53718 helo=mail.muc.de) by eggs.gnu.org with smtp (Exim 4.71) (envelope-from ) id 1ioAxE-0005Vh-CN for emacs-devel@gnu.org; Sun, 05 Jan 2020 13:48:48 -0500 Original-Received: (qmail 74722 invoked by uid 3782); 5 Jan 2020 18:48:46 -0000 Original-Received: from acm.muc.de (p2E5D50D2.dip0.t-ipconnect.de [46.93.80.210]) by colin.muc.de (tmda-ofmipd) with ESMTP; Sun, 05 Jan 2020 19:48:44 +0100 Original-Received: (qmail 16905 invoked by uid 1000); 5 Jan 2020 18:48:44 -0000 Content-Disposition: inline In-Reply-To: <83ftgtg43b.fsf@gnu.org> 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 [fuzzy] X-Received-From: 193.149.48.1 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.23 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:243991 Archived-At: Hello, Eli. On Sun, Jan 05, 2020 at 20:17:44 +0200, Eli Zaretskii wrote: > > Date: Sat, 4 Jan 2020 22:47:30 +0000 > > Cc: emacs-devel@gnu.org > > From: Alan Mackenzie > > OK. I have to say here, I really don't believe such an extensive > > commentary is needed here. The code is there, and anybody generally > > familiar with our C code would understand it without a great deal of > > difficulty, even the mechanism which prevents a spurious second call to > > prepare_to_modify_buffer. Surely? > If you think this is a waste of effort, you can leave the commentary > to me. It was more that that amount of commentary, 21 lines, could well get in the way, rather than being a help. > > For each iteration of the enclosing while (1) loop which > > yields data (i.e. nread > 0), before- and > > after-change-functions are each invoked exactly once. > > This is done directly from the current function only, by > > calling prepare_to_modify_buffer and signal_after_change. > > It is never done by directing another function such as > > insert_1_both to call them. > The last sentence above is inaccurate, since insert_1_both does call > prepare_to_modify_buffer. insert_1_both _can_ call prepare_to_modify_buffer, but only if it's directed to do so by setting its PREPARE parameter to true. Here it is set to false, to make it easier to keep control of the various prepare_to_modify_buffer's and signal_after_change's. How about changing the last sentence to: It is not done here by directing another function such as insert_1_both to call them. ? > Thanks. -- Alan Mackenzie (Nuremberg, Germany).