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: Wed, 28 Mar 2018 17:26:30 -0400 Message-ID: References: <20180324135024.GA6319@ACM> <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 X-Trace: blaine.gmane.org 1522272323 16695 195.159.176.226 (28 Mar 2018 21:25:23 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Wed, 28 Mar 2018 21:25:23 +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 Wed Mar 28 23:25:18 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 1f1IZK-0004G1-KW for ged-emacs-devel@m.gmane.org; Wed, 28 Mar 2018 23:25:18 +0200 Original-Received: from localhost ([::1]:41297 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1f1IbO-0004Mi-2r for ged-emacs-devel@m.gmane.org; Wed, 28 Mar 2018 17:27:26 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:49146) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1f1Iac-0004M4-1i for emacs-devel@gnu.org; Wed, 28 Mar 2018 17:26:39 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1f1IaX-0003xH-3T for emacs-devel@gnu.org; Wed, 28 Mar 2018 17:26:38 -0400 Original-Received: from pruche.dit.umontreal.ca ([132.204.246.22]:38465) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1f1IaW-0003xC-SS for emacs-devel@gnu.org; Wed, 28 Mar 2018 17:26:33 -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 w2SLQUk9001626; Wed, 28 Mar 2018 17:26:31 -0400 Original-Received: by pastel.home (Postfix, from userid 20848) id C3A0160834; Wed, 28 Mar 2018 17:26:30 -0400 (EDT) In-Reply-To: <20180328204254.GC6592@ACM> (Alan Mackenzie's message of "Wed, 28 Mar 2018 20:42:54 +0000") X-NAI-Spam-Flag: NO X-NAI-Spam-Level: X-NAI-Spam-Threshold: 5 X-NAI-Spam-Score: 0.7 X-NAI-Spam-Rules: 4 Rules triggered MAILTO_ONLY_JOB_NO_HTTP=0.5, AFF_LOTTO_1=0.2, EDT_SA_DN_PASS=0, RV6252=0 X-NAI-Spam-Version: 2.3.0.9418 : core <6252> : inlines <6528> : streams <1782540> : uri <2616457> 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:224128 Archived-At: > 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, than I'd want this new extension to be generic rather than specific for this particular use-case. > But I suspect that the mechanism you suggested (an `apply' format > element recursively calling primitive-undo), will break other packages > too, even if the format of undo lists isn't changed. Could be, indeed. > 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. 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). > 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". > 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. and no, I don't know why we do this. Stefan