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: Wed, 28 Mar 2018 20:42:54 +0000 Message-ID: <20180328204254.GC6592@ACM> References: <20180324135024.GA6319@ACM> <20180325191424.GE6292@ACM> <20180326201728.GA28620@ACM> <20180327165816.GB4105@ACM> <20180327194507.GD4105@ACM> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: blaine.gmane.org 1522269802 6289 195.159.176.226 (28 Mar 2018 20:43:22 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Wed, 28 Mar 2018 20:43:22 +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 Wed Mar 28 22:43: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 1f1Huf-0001Xn-IY for ged-emacs-devel@m.gmane.org; Wed, 28 Mar 2018 22:43:17 +0200 Original-Received: from localhost ([::1]:40927 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1f1Hwj-0006dM-5u for ged-emacs-devel@m.gmane.org; Wed, 28 Mar 2018 16:45:25 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:39381) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1f1Hu8-00052W-2X for emacs-devel@gnu.org; Wed, 28 Mar 2018 16:42:45 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1f1Hu4-00010Y-SV for emacs-devel@gnu.org; Wed, 28 Mar 2018 16:42:44 -0400 Original-Received: from colin.muc.de ([193.149.48.1]:54453 helo=mail.muc.de) by eggs.gnu.org with smtp (Exim 4.71) (envelope-from ) id 1f1Hu4-00010B-Gl for emacs-devel@gnu.org; Wed, 28 Mar 2018 16:42:40 -0400 Original-Received: (qmail 97381 invoked by uid 3782); 28 Mar 2018 20:42:38 -0000 Original-Received: from acm.muc.de (p5B1475D2.dip0.t-ipconnect.de [91.20.117.210]) by colin.muc.de (tmda-ofmipd) with ESMTP; Wed, 28 Mar 2018 22:42:37 +0200 Original-Received: (qmail 19301 invoked by uid 1000); 28 Mar 2018 20:42:54 -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:224127 Archived-At: Hello, Stefan. On Tue, Mar 27, 2018 at 16:24:28 -0400, Stefan Monnier wrote: > >> See http://elpa.gnu.org/packages/undo-tree.html > > Interesting. But I think it would be overkill for me personally. > The point is not to make you use it, but that this package uses the same > buffer-undo-list, so any change to the format would break it. It would need amendment, of course, but that wouldn't be difficult. 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. We'd have to try it out. > > I really don't want to do this [combining all the undo elements into > > a single undo element]. Some people will want to analyse > > buffer-undo-list and such a replacement will throw off this > > analysis, possibly to the extent of making it useless. > How/why? I can't think of any case where it would cause such problems: > the resulting undo-list, tho less detailed than the original one, is > perfectly valid. You put it most eloquently yourself in Subject: Re: What improvements would be truly useful? Date: Thu, 08 Mar 2018 23:43:57 -0500: Of course Emacs can also hide information (as text-properties, as invisible text, as data stored in buffer-local variables, ...) but most packages follow a design where as little info as possible is hidden. Indeed, whenever I hide such information, I think it over many times because I know there's a very strong chance that users won't like it. 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. Incidentally, position elements in the undo list don't work: `undo' removes them from buffer-undo-list. 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. > Stefan -- Alan Mackenzie (Nuremberg, Germany).