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: Sat, 31 Mar 2018 19:38:03 -0400 Message-ID: References: <20180327194507.GD4105@ACM> <20180328204254.GC6592@ACM> <20180329151033.GA5213@ACM> <20180329171101.GB5213@ACM> <20180330114636.GA5432@ACM> <20180331210052.GB5003@ACM> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: blaine.gmane.org 1522539378 14206 195.159.176.226 (31 Mar 2018 23:36:18 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Sat, 31 Mar 2018 23:36:18 +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 01:36:14 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 1f2Q2f-0003Xk-R8 for ged-emacs-devel@m.gmane.org; Sun, 01 Apr 2018 01:36:13 +0200 Original-Received: from localhost ([::1]:37029 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1f2Q4h-0005Ry-I0 for ged-emacs-devel@m.gmane.org; Sat, 31 Mar 2018 19:38:19 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:48726) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1f2Q4Y-0005Rh-CV for emacs-devel@gnu.org; Sat, 31 Mar 2018 19:38:11 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1f2Q4V-0003YP-9N for emacs-devel@gnu.org; Sat, 31 Mar 2018 19:38:10 -0400 Original-Received: from pruche.dit.umontreal.ca ([132.204.246.22]:55367) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1f2Q4V-0003Xj-1f for emacs-devel@gnu.org; Sat, 31 Mar 2018 19:38:07 -0400 Original-Received: from pastel.home (lechon.iro.umontreal.ca [132.204.27.242]) by pruche.dit.umontreal.ca (8.14.7/8.14.1) with ESMTP id w2VNc3Wu008724; Sat, 31 Mar 2018 19:38:04 -0400 Original-Received: by pastel.home (Postfix, from userid 20848) id 9E5086018D; Sat, 31 Mar 2018 19:38:03 -0400 (EDT) In-Reply-To: <20180331210052.GB5003@ACM> (Alan Mackenzie's message of "Sat, 31 Mar 2018 21:00:52 +0000") X-NAI-Spam-Flag: NO X-NAI-Spam-Threshold: 5 X-NAI-Spam-Score: 0 X-NAI-Spam-Rules: 2 Rules triggered EDT_SA_DN_PASS=0, RV6254=0 X-NAI-Spam-Version: 2.3.0.9418 : core <6254> : inlines <6533> : streams <1782835> : uri <2618273> X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 132.204.246.22 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:224213 Archived-At: > > (defun wrap-and-run-primitive-undo (beg end list) > > (combine-change-calls > That's a refinement I haven't managed to get around to, yet. Any difficulty there? Naively, I'd expect that it's just a matter of: (defun undo--wrap-and-run-primitive-undo (beg end list) (combine-change-calls (while list (setq list (primitive-undo 1 list))))) [ and of course, making sure this function is defined after the combine-change-calls macro. ] >> (defmacro combine-change-calls (beg end &rest forms) >> `(combine-change-calls-function ,beg ,end (lambda () ,@forms))) > DONE, at least with the name combine-change-calls-1. Good. > I don't really like "...-function", since that suggests > a hook variable. I'm not too fond of those either for the same reason, although I must admit to using such names occasionally. > Not only can, but does. I spent around 2 hours yesterday waiting for > this infinite loop to terminate. ;-( I'm sure it was just a question of time. > It is, of course, garbage collection which lops off the element we're > looking for, particularly when commenting out a large region. Yes, that should be the most common reason. > So, I think this exercise is worthwhile. I have added some doc strings > to the functions. I have introduced a variable to hinder a "recursive" > undo--wrap-and-run-primitive-undo appearing in the undo list. This > happened with uncomment-region calling comment-region. That's weird: shouldn't the inhibit-modification-hooks already play this role? Oh, wait, I see you don't test inhibit-modification-hooks any more but you test undo--combining-change-calls instead. Any particular reason for this change? > Sometimes, point ends up at the wrong place after an undo (probably > because of primitive-undo removing POSITION elements from undo-lists, as > we've already discussed.) The code that removes those "position" elements is in `undo`, not in `primitive-undo`, so what you're describing must come from something else (unless you're seeing this when *redoing* or *reundoing*). Stefan