From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Stefan Monnier Newsgroups: gmane.emacs.devel Subject: Re: [Emacs-diffs] emacs-26 671dc5a: Fix calls to buffer modification hooks from replace-buffer-contents Date: Sat, 21 Jul 2018 16:46:47 -0400 Message-ID: References: <20180721180616.6608.26581@vcs0.savannah.gnu.org> <20180721180618.5CEA9208D4@vcs0.savannah.gnu.org> <83bmb0xxcy.fsf@gnu.org> <838t64xwqe.fsf@gnu.org> <836018xvux.fsf@gnu.org> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: blaine.gmane.org 1532205896 23134 195.159.176.226 (21 Jul 2018 20:44:56 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Sat, 21 Jul 2018 20:44:56 +0000 (UTC) User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.0.50 (gnu/linux) Cc: emacs-devel@gnu.org To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sat Jul 21 22:44:51 2018 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 1fgykF-0005v4-G2 for ged-emacs-devel@m.gmane.org; Sat, 21 Jul 2018 22:44:51 +0200 Original-Received: from localhost ([::1]:53940 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1fgymM-0001Z8-BK for ged-emacs-devel@m.gmane.org; Sat, 21 Jul 2018 16:47:02 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:41635) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1fgymD-0001Yw-6Z for emacs-devel@gnu.org; Sat, 21 Jul 2018 16:46:54 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1fgymC-0007qJ-Bf for emacs-devel@gnu.org; Sat, 21 Jul 2018 16:46:53 -0400 Original-Received: from pmta21.teksavvy.com ([76.10.157.36]:59872) by eggs.gnu.org with esmtps (TLS1.0:RSA_ARCFOUR_SHA1:16) (Exim 4.71) (envelope-from ) id 1fgym8-0007pe-Mj; Sat, 21 Jul 2018 16:46:48 -0400 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A2FZAwA0m1Nb/37rr2xcGgEBAQEBAgEBA?= =?us-ascii?q?QEIAQEBAYNNgWKNCYtTAYILEx4BlwULhGYEAgKDDCI4FAECAQEBAQEBAgICaSi?= =?us-ascii?q?FOQEEAVYjBQsLNAcLFBgNJIUrCK9qik6LGIN0LoRGhg0CkXiHdAmXQYVhkhUMg?= =?us-ascii?q?VgigVIzGggwgyWCTI4iI4whgkkBAQ?= X-IPAS-Result: =?us-ascii?q?A2FZAwA0m1Nb/37rr2xcGgEBAQEBAgEBAQEIAQEBAYNNgWK?= =?us-ascii?q?NCYtTAYILEx4BlwULhGYEAgKDDCI4FAECAQEBAQEBAgICaSiFOQEEAVYjBQsLN?= =?us-ascii?q?AcLFBgNJIUrCK9qik6LGIN0LoRGhg0CkXiHdAmXQYVhkhUMgVgigVIzGggwgyW?= =?us-ascii?q?CTI4iI4whgkkBAQ?= X-IronPort-AV: E=Sophos;i="5.51,386,1526356800"; d="scan'208";a="40083967" Original-Received: from 108-175-235-126.dsl.teksavvy.com (HELO fmsmemgm.homelinux.net) ([108.175.235.126]) by smtp.teksavvy.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 21 Jul 2018 16:46:47 -0400 Original-Received: by fmsmemgm.homelinux.net (Postfix, from userid 20848) id 6E89EAE0E4; Sat, 21 Jul 2018 16:46:47 -0400 (EDT) In-Reply-To: <836018xvux.fsf@gnu.org> (Eli Zaretskii's message of "Sat, 21 Jul 2018 21:54:46 +0300") X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 76.10.157.36 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:227643 Archived-At: >> >> I don't understand enough of the code to have an opinion on it, but the >> >> comments describe a behavior which would be wrong: both before-c-f and >> >> after-c-f- need to be run for any buffer change, even if it's only an >> >> insertion or only a deletion. >> > What if there's no change at all, i.e. no deletions and no insertions? >> Then you can either run neither of the hooks, or both. > How can we determine whether to run neither or not? You can roll a dice. > I can easily run both, but is that TRT? It was you who requested not > to run the hooks on a range that is larger than we can determine by > looking at the results of compareseq. Running both would not be a bug: it would be sub-optimal but not incorrect (just like your original choice of running the hooks over the whole buffer). If it's easy to do the better choice is to do nothing. > The recipe describes a case where "foo" is replaced by "foo", and the > code in compareseq tells us not to change anything. There are no > deletions and no insertions. Do we call the modification hooks in > this case? If we can refrain from calling them, it's better to do that. But this thread is not about the case described in the bug-report, where there's been no change. It's about the text in the two comments you introduced: they say (or at least can be interpreted to say) that the code may run only one of the two hooks in some cases. If that text is a correct description of the code, it means we have a bug in the code, and if not it means those comments should be improved. Stefan