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: Thu, 29 Mar 2018 11:40:26 -0400 Message-ID: References: <20180325191424.GE6292@ACM> <20180326201728.GA28620@ACM> <20180327165816.GB4105@ACM> <20180327194507.GD4105@ACM> <20180328204254.GC6592@ACM> <20180329151033.GA5213@ACM> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: blaine.gmane.org 1522337994 17985 195.159.176.226 (29 Mar 2018 15:39:54 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Thu, 29 Mar 2018 15:39:54 +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 Thu Mar 29 17:39:49 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 1f1ZeX-0004bW-Ee for ged-emacs-devel@m.gmane.org; Thu, 29 Mar 2018 17:39:49 +0200 Original-Received: from localhost ([::1]:34606 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1f1Zgb-0001iF-0X for ged-emacs-devel@m.gmane.org; Thu, 29 Mar 2018 11:41:57 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:42148) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1f1ZfG-0001JK-5b for emacs-devel@gnu.org; Thu, 29 Mar 2018 11:40:35 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1f1ZfB-00058D-7K for emacs-devel@gnu.org; Thu, 29 Mar 2018 11:40:34 -0400 Original-Received: from pruche.dit.umontreal.ca ([132.204.246.22]:49982) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1f1ZfA-000559-Ke for emacs-devel@gnu.org; Thu, 29 Mar 2018 11:40:28 -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 w2TFeQXv020818; Thu, 29 Mar 2018 11:40:26 -0400 Original-Received: by pastel.home (Postfix, from userid 20848) id 28CEE60559; Thu, 29 Mar 2018 11:40:26 -0400 (EDT) In-Reply-To: <20180329151033.GA5213@ACM> (Alan Mackenzie's message of "Thu, 29 Mar 2018 15:10:33 +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, RV6253=0 X-NAI-Spam-Version: 2.3.0.9418 : core <6253> : inlines <6528> : streams <1782613> : uri <2616902> 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:224159 Archived-At: > I don't think "consider" is the right word here. I don't think it will > work at all. I expect otherwise. > In primitive-undo, some undo list is an argument, and it > has elements removed from it and it is then the return value. If we try > to call primitive-undo recursively through an (apply ...) form, there is > no interface to return the depleted list to the calling p-u. You keep assuming a shape like ...previous elements... (apply ....) ...undo-elements... (apply ....) ...subsequent elements... where I'm assuming a shape like: ...previous elements... (apply .... ...undo-elements...) ...subsequent elements... I don't see any part of primitive-undo which would prevent it being used recursively in such a situation. >> ... than I'd want this new extension to be generic rather than >> specific for this particular use-case. > It is generic, in the sense it handles any case where > before/after-change-functions are to be condensed into one call of each. > What do you mean by generic, here? That it can be used by other things than combine-change-calls. I.e. generic is the same sense as the (apply ....) thingy is generic. > It does a good deal more than "optimizing the representation" - it makes > an irreversible change which loses information. To the extent that most execution of code makes irreversible changes, I agree, but other than that, I fail to see what information you're thinking about. > Somebody, sometime, is going to need that info. Could you give some hypothetical example to give me an idea of what kind of info you're thinking of and where/when it might be needed? >> Whatever you decide to do with the undo-log, handling undo-boundary >> pushed during the execution of `body` will be tricky I suspect (except >> if we just don't touch the undo-list, of course). > In my current code, the only undo-boundary pushed (in the handling of > combine-change-begin) is immediately acted upon to terminate the > recursive invocation of primitive-undo. This is pushed onto the LIST > variable in the nested p-u, and doesn't affect buffer-undo-list or > pending-undo-list. I'm referring to undo-boundaries pushed by the "execution of `body`", not by your code. IIUC we agree that this is considered an unimportant use-case and it's OK to just ignore such boundaries. >> IIUC The code you cite only strips them from the undo elements added >> while performing an undo (i.e. from "redo" elements), so they should >> still work for a plain "edit .... undo". > Ah, is that it? I had some difficulty understanding it properly. Yes, that's it. I don't think it affects this discussion at all. Stefan