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: An idea: combine-change-calls Date: Sun, 01 Apr 2018 15:22:33 -0400 Message-ID: References: <20180328204254.GC6592@ACM> <20180329151033.GA5213@ACM> <20180329171101.GB5213@ACM> <20180330114636.GA5432@ACM> <20180331210052.GB5003@ACM> <20180401142410.GA9027@ACM> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: blaine.gmane.org 1522610446 11640 195.159.176.226 (1 Apr 2018 19:20:46 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Sun, 1 Apr 2018 19:20:46 +0000 (UTC) User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.0.50 (gnu/linux) Cc: emacs-devel@gnu.org To: Alan Mackenzie Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sun Apr 01 21:20:42 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 1f2iWu-0002rq-55 for ged-emacs-devel@m.gmane.org; Sun, 01 Apr 2018 21:20:40 +0200 Original-Received: from localhost ([::1]:57058 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1f2iYw-0007PD-6t for ged-emacs-devel@m.gmane.org; Sun, 01 Apr 2018 15:22:46 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:56859) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1f2iYq-0007OJ-3n for emacs-devel@gnu.org; Sun, 01 Apr 2018 15:22:41 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1f2iYm-0004G9-4M for emacs-devel@gnu.org; Sun, 01 Apr 2018 15:22:40 -0400 Original-Received: from pmta21.teksavvy.com ([76.10.157.36]:44267) by eggs.gnu.org with esmtps (TLS1.0:RSA_ARCFOUR_SHA1:16) (Exim 4.71) (envelope-from ) id 1f2iYl-0004Et-VE for emacs-devel@gnu.org; Sun, 01 Apr 2018 15:22:36 -0400 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A2GZCQAqMMFa/06mSC1dHAEBAQQBAQoBA?= =?us-ascii?q?YMTL4FQiCaQX4F0E3yUTQuFBAKEJiE3FQECAQEBAQEBAgNoKIUmAQQBeQULCw0?= =?us-ascii?q?BJhIUGDGFGAiwXxoCiB+CK4dhghOEEIpDApBEhnYIlV8ihGSPfYElMiOBUjMaC?= =?us-ascii?q?DA6gkSCHxeOMiOOMAEB?= X-IPAS-Result: =?us-ascii?q?A2GZCQAqMMFa/06mSC1dHAEBAQQBAQoBAYMTL4FQiCaQX4F?= =?us-ascii?q?0E3yUTQuFBAKEJiE3FQECAQEBAQEBAgNoKIUmAQQBeQULCw0BJhIUGDGFGAiwX?= =?us-ascii?q?xoCiB+CK4dhghOEEIpDApBEhnYIlV8ihGSPfYElMiOBUjMaCDA6gkSCHxeOMiO?= =?us-ascii?q?OMAEB?= X-IronPort-AV: E=Sophos;i="5.48,392,1517893200"; d="scan'208";a="25768332" Original-Received: from unknown (HELO fmsmemgm.homelinux.net) ([45.72.166.78]) by smtp.teksavvy.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 01 Apr 2018 15:22:33 -0400 Original-Received: by fmsmemgm.homelinux.net (Postfix, from userid 20848) id 6B97AAE0D4; Sun, 1 Apr 2018 15:22:33 -0400 (EDT) In-Reply-To: <20180401142410.GA9027@ACM> (Alan Mackenzie's message of "Sun, 1 Apr 2018 14:24:10 +0000") 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:224226 Archived-At: >> That's weird: shouldn't the inhibit-modification-hooks already play this role? > I don't think so. i-m-h is purely to do with whether the hooks should > be run now. That has nothing to do with how items should be added to > the undo list. Ah, I see what you mean. [ tho I think in practice, there'll be no difference: the code which binds inhibit-modification-hooks in the context will already want to deal with the fact that the undo entries would normally not be run within such a inhibit-modification-hooks, so it'll usually bind buffer-undo-list to t or do something related. ] > I'm not sure. I think it's in re-undoing. Yes, that would be expected, indeed. > As you've already guessed, I would be in favour of removing that code > from `undo' that we don't see what it's for. As I said, it's orthogonal to the current discussion (it affects many more cases). And I personally have no opinion on whether this behavior should be considered as a bug or a feature. > I think it's almost time to commit this to master. Agreed. > I propose that combine-change-calls{-1,} go into subr.el, beside > combine-after-change-calls, and undo--wrap-and-run-primitive-undo go > into simple.el, beside the rest of the undo stuff. I don't have an opinion on which file it should go to, but undo--wrap-and-run-primitive-undo belongs with the rest, so it'd make a lot more sense to keep them all three together. > I will introduce the variable comment-combine-change-calls in > newcomment.el, and modify {,un}comment-region to test it, and if set, to > use c-c-c. I'm not sure we even need such a variable (tho I'd put the combine-change-calls around comment-region-default, so it doesn't affect other settings of comment-region-function). > I will document c-c-c in the Elisp manual on page "Change Hooks". Thanks. Stefan