From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.ciao.gmane.io!not-for-mail From: Alan Mackenzie Newsgroups: gmane.emacs.devel Subject: Re: /* FIXME: Call signal_after_change! */ in callproc.c. Well, why not? Date: Tue, 21 Jan 2020 20:34:53 +0000 Message-ID: <20200121203453.GB4002@ACM> References: <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> <20200105184844.GB4377@ACM> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Injection-Info: ciao.gmane.io; posting-host="ciao.gmane.io:159.69.161.202"; logging-data="57236"; mail-complaints-to="usenet@ciao.gmane.io" 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-mx.org@gnu.org Tue Jan 21 21:35:32 2020 Return-path: Envelope-to: ged-emacs-devel@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1iu0FI-000EmR-RK for ged-emacs-devel@m.gmane-mx.org; Tue, 21 Jan 2020 21:35:32 +0100 Original-Received: from localhost ([::1]:60710 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1iu0FH-0002z3-T4 for ged-emacs-devel@m.gmane-mx.org; Tue, 21 Jan 2020 15:35:31 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:41954) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1iu0Ej-0002UU-OA for emacs-devel@gnu.org; Tue, 21 Jan 2020 15:34:58 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1iu0Ei-0004fR-JK for emacs-devel@gnu.org; Tue, 21 Jan 2020 15:34:57 -0500 Original-Received: from colin.muc.de ([193.149.48.1]:16644 helo=mail.muc.de) by eggs.gnu.org with smtp (Exim 4.71) (envelope-from ) id 1iu0Ei-0004eX-AR for emacs-devel@gnu.org; Tue, 21 Jan 2020 15:34:56 -0500 Original-Received: (qmail 68415 invoked by uid 3782); 21 Jan 2020 20:34:55 -0000 Original-Received: from acm.muc.de (p4FE15B84.dip0.t-ipconnect.de [79.225.91.132]) by colin.muc.de (tmda-ofmipd) with ESMTP; Tue, 21 Jan 2020 21:34:53 +0100 Original-Received: (qmail 6233 invoked by uid 1000); 21 Jan 2020 20:34:53 -0000 Content-Disposition: inline In-Reply-To: <20200105184844.GB4377@ACM> 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-mx.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.io gmane.emacs.devel:244477 Archived-At: Hello, Eli. Ping? Could we move forward with this, please? On Sun, Jan 05, 2020 at 18:48:44 +0000, Alan Mackenzie wrote: > 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). -- Alan Mackenzie (Nuremberg, Germany).