From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED.blaine.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Re: /* FIXME: Call signal_after_change! */ in callproc.c. Well, why not? Date: Tue, 24 Dec 2019 17:47:18 +0200 Message-ID: <837e2lwws9.fsf@gnu.org> References: <20191221172324.GA8692@ACM> <83k16pzgzu.fsf@gnu.org> <20191221214751.GB8692@ACM> <83sglcxl1q.fsf@gnu.org> <20191224094724.GA3992@ACM> Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226"; logging-data="186128"; mail-complaints-to="usenet@blaine.gmane.org" Cc: emacs-devel@gnu.org To: Alan Mackenzie Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Dec 24 16:48:19 2019 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 1ijmPz-000mI2-Pj for ged-emacs-devel@m.gmane.org; Tue, 24 Dec 2019 16:48:19 +0100 Original-Received: from localhost ([::1]:40026 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1ijmPy-0004UG-DO for ged-emacs-devel@m.gmane.org; Tue, 24 Dec 2019 10:48:18 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:34330) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1ijmPE-00042j-7C for emacs-devel@gnu.org; Tue, 24 Dec 2019 10:47:33 -0500 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]:45492) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ijmPD-00072U-S0; Tue, 24 Dec 2019 10:47:31 -0500 Original-Received: from [176.228.60.248] (port=1294 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1ijmPD-0005Eg-90; Tue, 24 Dec 2019 10:47:31 -0500 In-reply-to: <20191224094724.GA3992@ACM> (message from Alan Mackenzie on Tue, 24 Dec 2019 09:47:24 +0000) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] 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:243614 Archived-At: > Date: Tue, 24 Dec 2019 09:47:24 +0000 > Cc: emacs-devel@gnu.org > From: Alan Mackenzie > > The point is not to call prepare_to_modify_buffer twice at the same > position. Why is that a problem? Surely, something like that can happen in real life, and any modification hook should be prepared to deal with that? > > I think you should simply call signal_after_change after the call to > > del_range_2 (telling the after-change hooks that actually nothing was > > inserted or deleted). Then you won't need the prepared_position > > thingy. > > After thinking it over a couple of days, I can't agree this is a good > idea. Calling before/after-change-functions for a non-change would be > very unusual in Emacs - I don't know of anywhere where this is currently > done - and would surely cause problems somewhere, and would certainly > cause some inefficiency. Also we would have to amend the Change Hooks > page in the Elisp manual to warn of this possibility. Again, I don't see why this could cause any trouble. Inserting an empty string is not an outlandish situation, and any modification hook must be prepared to (trivially) deal with it. IOW, jumping through hoops in order to avoid such calls is IMNSHO unjustified. It will definitely complicate code, and thus will run higher risk of subtle bugs. Why risk that?