From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Alan Mackenzie Newsgroups: gmane.emacs.devel Subject: Re: An idea: combine-change-calls Date: Thu, 29 Mar 2018 17:11:01 +0000 Message-ID: <20180329171101.GB5213@ACM> References: <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; charset=us-ascii X-Trace: blaine.gmane.org 1522343385 12571 195.159.176.226 (29 Mar 2018 17:09:45 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Thu, 29 Mar 2018 17:09:45 +0000 (UTC) User-Agent: Mutt/1.7.2 (2016-11-26) Cc: emacs-devel@gnu.org To: Stefan Monnier Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Thu Mar 29 19:09:41 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 1f1b3U-0003B2-VO for ged-emacs-devel@m.gmane.org; Thu, 29 Mar 2018 19:09:41 +0200 Original-Received: from localhost ([::1]:41284 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1f1b5Y-00016L-C5 for ged-emacs-devel@m.gmane.org; Thu, 29 Mar 2018 13:11:48 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:53285) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1f1b4n-00015s-7T for emacs-devel@gnu.org; Thu, 29 Mar 2018 13:11:02 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1f1b4k-0003fu-1b for emacs-devel@gnu.org; Thu, 29 Mar 2018 13:11:01 -0400 Original-Received: from colin.muc.de ([193.149.48.1]:29145 helo=mail.muc.de) by eggs.gnu.org with smtp (Exim 4.71) (envelope-from ) id 1f1b4j-0003eF-Dv for emacs-devel@gnu.org; Thu, 29 Mar 2018 13:10:57 -0400 Original-Received: (qmail 54608 invoked by uid 3782); 29 Mar 2018 17:10:55 -0000 Original-Received: from acm.muc.de (p5B147429.dip0.t-ipconnect.de [91.20.116.41]) by colin.muc.de (tmda-ofmipd) with ESMTP; Thu, 29 Mar 2018 19:10:54 +0200 Original-Received: (qmail 5568 invoked by uid 1000); 29 Mar 2018 17:11:01 -0000 Content-Disposition: inline In-Reply-To: X-Delivery-Agent: TMDA/1.1.12 (Macallan) X-Primary-Address: acm@muc.de X-detected-operating-system: by eggs.gnu.org: FreeBSD 9.x [fuzzy] X-Received-From: 193.149.48.1 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:224161 Archived-At: Hello, Stefan. On Thu, Mar 29, 2018 at 11:40:26 -0400, Stefan Monnier wrote: > > I don't think "consider" is the right word here. I don't think it will > > work at all. > I expect otherwise. [ .... ] > 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 think you've just drawn two pictures of possible undo lists. > I don't see any part of primitive-undo which would prevent it being used > recursively in such a situation. Right, I think I've got it now. The macro combine-change-calls would maybe first push some sort of sentinal element onto buffer-undo-list, then let ,@forms run, then massage the list so that the 2000 elements created by ,@forms would become part of the `apply' element. Yes, that would work. :-) I will implement this. > >> ... 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. I still don't understand. What other things could possibly be similiar enough to collecting before/after-change-functions to be abstractable into some sort of parameter? Could you give an example? > > 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? The information is the original undo entries created by the Emacs primitives whilst in combine-change-calls. As to where/when/why it might be needed, I couldn't say at this point. Somebody, sometime, will want it for some reason, just like you said in your piece about "hiding information" I quoted a short while ago. Why are you so keen to destroy this detailed information? Its continued existence does not cause any disadvantage. The run time which would be saved in `undo' is minimal and inconsequential. > >> 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. OK. We could amend primitive-undo such that the argument N could, additionally, take the value t, meaning "undo all elements in the list, ignoring nils". Or something like that. > IIUC we agree that this is considered an unimportant use-case and it's > OK to just ignore such boundaries. I suppose so. What would such a boundary mean anyway? We're talking about a scenario where all the change hook invocations are amalgamated. How could it make sense to split that up? > >> 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. I suppose not. Not at the moment, anyway. > Stefan -- Alan Mackenzie (Nuremberg, Germany).