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 15:10:33 +0000 Message-ID: <20180329151033.GA5213@ACM> References: <20180325191424.GE6292@ACM> <20180326201728.GA28620@ACM> <20180327165816.GB4105@ACM> <20180327194507.GD4105@ACM> <20180328204254.GC6592@ACM> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: blaine.gmane.org 1522336125 13467 195.159.176.226 (29 Mar 2018 15:08:45 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Thu, 29 Mar 2018 15:08: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 17:08: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 1f1ZAN-0003Qs-WC for ged-emacs-devel@m.gmane.org; Thu, 29 Mar 2018 17:08:40 +0200 Original-Received: from localhost ([::1]:60528 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1f1ZCR-00041y-7J for ged-emacs-devel@m.gmane.org; Thu, 29 Mar 2018 11:10:47 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:47882) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1f1ZCE-00040D-6o for emacs-devel@gnu.org; Thu, 29 Mar 2018 11:10:35 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1f1ZC9-0003ij-SA for emacs-devel@gnu.org; Thu, 29 Mar 2018 11:10:34 -0400 Original-Received: from colin.muc.de ([193.149.48.1]:49556 helo=mail.muc.de) by eggs.gnu.org with smtp (Exim 4.71) (envelope-from ) id 1f1ZC9-0003em-Hz for emacs-devel@gnu.org; Thu, 29 Mar 2018 11:10:29 -0400 Original-Received: (qmail 21265 invoked by uid 3782); 29 Mar 2018 15:10:28 -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 17:10:27 +0200 Original-Received: (qmail 5286 invoked by uid 1000); 29 Mar 2018 15:10:33 -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:224157 Archived-At: Hello, Stefan. On Wed, Mar 28, 2018 at 17:26:30 -0400, Stefan Monnier wrote: > > It would need amendment, of course, but that wouldn't be difficult. > I'd rather try and avoid that. And if we really do want to extent the > format because we consider that (apply ...) is not good enough here, > .... I don't think "consider" is the right word here. I don't think it will work at all. 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. We could, of course, use some global variables instead of arguments, but this would involve changes just as incompatible as making additions to the undo list elements. > ... 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? [ .... ] > > What we've been discussing goes beyond hiding information, it is the > > destruction of information. Users, maybe just a few, won't like > > that at all. > Not at all. It's just optimizing the representation of the undo-log. > If there's an undo-boundary in there, then indeed, we'd be throwing away > a bit of information, but I assumed we wouldn't care about that case. It does a good deal more than "optimizing the representation" - it makes an irreversible change which loses information. Somebody, sometime, is going to need that info. > 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. > > Incidentally, position elements in the undo list don't work: `undo' > > removes them from buffer-undo-list. > Are you sure they "don't work" (they seemed to work in my test)? > 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. > > I think you amended that bit of code some years ago. Can you say why > > this is done? The comment in the code: > > ;; Don't specify a position in the undo record for the undo command. > > ;; Instead, undoing this should move point to where the change is. > > doesn't give any reason, and the various pertinent commit messages > > aren't any help either. > Hmm... good question. I see this code basically dates back to > commit 2512c9f0f0e6cc71c601ffdb0690b9cf5642734b > Author: Richard M. Stallman > Date: Wed Mar 16 23:41:32 1994 +0000 > (undo): Don't let the undo entries for the undo > contain a specific buffer position. Delete it if there is one. Yes. > and no, I don't know why we do this. Thinking about it, that comment above ("Don't specify a position ....") reads as if it was originally in place on some code which added elements to buffer-undo-list, and then got hurredly moved to `undo' when the strategy was changed to delete such elements. Again, it isn't clear why position elements get deleted. Any code which adds them (such as my new code) will have a reason for doing so. > Stefan -- Alan Mackenzie (Nuremberg, Germany).