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: Tue, 27 Mar 2018 19:45:07 +0000 Message-ID: <20180327194507.GD4105@ACM> References: <20180324135024.GA6319@ACM> <20180325191424.GE6292@ACM> <20180326201728.GA28620@ACM> <20180327165816.GB4105@ACM> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: blaine.gmane.org 1522181009 9840 195.159.176.226 (27 Mar 2018 20:03:29 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Tue, 27 Mar 2018 20:03:29 +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 Tue Mar 27 22:03:24 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 1f0uoW-0002TX-PY for ged-emacs-devel@m.gmane.org; Tue, 27 Mar 2018 22:03:24 +0200 Original-Received: from localhost ([::1]:35870 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1f0uqa-0001Jl-CY for ged-emacs-devel@m.gmane.org; Tue, 27 Mar 2018 16:05:32 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:47276) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1f0upk-0001JI-Nj for emacs-devel@gnu.org; Tue, 27 Mar 2018 16:04:41 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1f0upg-0001Zq-Pz for emacs-devel@gnu.org; Tue, 27 Mar 2018 16:04:40 -0400 Original-Received: from colin.muc.de ([193.149.48.1]:18568 helo=mail.muc.de) by eggs.gnu.org with smtp (Exim 4.71) (envelope-from ) id 1f0upg-0001Zd-Iu for emacs-devel@gnu.org; Tue, 27 Mar 2018 16:04:36 -0400 Original-Received: (qmail 24219 invoked by uid 3782); 27 Mar 2018 20:04:34 -0000 Original-Received: from acm.muc.de (p5B14757F.dip0.t-ipconnect.de [91.20.117.127]) by colin.muc.de (tmda-ofmipd) with ESMTP; Tue, 27 Mar 2018 22:04:33 +0200 Original-Received: (qmail 16315 invoked by uid 1000); 27 Mar 2018 19:45:07 -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:224105 Archived-At: Hello again, Stefan. On Tue, Mar 27, 2018 at 14:30:53 -0400, Stefan Monnier wrote: > > happens to undo-entries which aren't in the region. Maybe they are > > just discarded, maybe they are somehow kept in the undo list. > They're just discarded (when building the list to pass to > primitive-undo only: they stay in buffer-undo-list, of course). OK. > > By the way, what's undo-tree? I've not been able to find that symbol at > > all in the source code. > See http://elpa.gnu.org/packages/undo-tree.html Interesting. But I think it would be overkill for me personally. > >> Better use the (apply DELTA BEG END FUN-NAME . ARGS) form, which was > >> introduced specifically for use of such extensions. > > This won't work, at least not without some seriously twisted coding: The > > essential thing about (combine-change-end/begin ..) is that they bind > > inhibit-modification-hooks to non-nil for other entries in the > > undo-list. Maybe FUN-NAME could call primitive-undo, but this doesn't > > seem wise. > Actually the way I was thinking of using it was something like: > (let ((elem-apply `(apply 0 ,beg ,end ,#'my-undo-combining nil))) > (push elem-apply buffer-undo-list) > (funcall body) > (let ((new-bul (memq elem-apply buffer-undo-list))) > (when new-bul > (let ((undo-elems buffer-undo-list)) > (setf (nthcdr (- (length undo-elems) (length new-bul)) > undo-elems) > nil) > (setf (nth 1 elem-apply) (- end-marker end)) > (setf (nth 3 elem-apply) (marker-position end-marker)) > (setf (nth 5 elem-apply) undo-elems) > (setq buffer-undo-list new-bul))))) > and then > (defun my-undo-combining (undo-elems) > (let ((inhibit-modification-hooks t)) > (while t > (primitive-undo 1 undo-elems)))) OK, I get the general idea: there's a recursive call to primitive-undo from the FUN-NAME in the `apply' undo element. But it's actually more complicated still: When the undo is in progress, FUN-NAME must push (a) new `apply' element(s) to buffer-undo-list for the use of a possible redo. This is probably possible, but my head's beginning to hurt at the moment. ;-) My scheme (of introducing new types of element to the undo list) is quite a bit simpler, but has the disadvantage of an incompatible change in the undo list format. I accept that this disadvantage is severe. I think I will continue to refine my scheme to get practice and experience. Then will be the time to decide on replacing it with the above `apply' scheme. > But you might prefer just replacing the whole thing with a pair of > insert+delete, which is simpler and vastly more efficient (but with the > disadvantage that it doesn't preserve markers quite as well). I really don't want to do this. 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. In practice, wrapping the original undo elements in what we've been talking about is easily fast enough. (An undo over ~2000 lines of comment-region'd C++ code was taking ~0.05s (if I remember correctly), though displaying it after that took appreciably longer.) > Stefan -- Alan Mackenzie (Nuremberg, Germany).