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: Mon, 2 Apr 2018 16:25:57 +0000 Message-ID: <20180402162557.GA16027@ACM> References: <20180324135024.GA6319@ACM> <20180325191424.GE6292@ACM> <20180326201728.GA28620@ACM> <87zi2qkjui.fsf@gnu.org> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: blaine.gmane.org 1522686274 17952 195.159.176.226 (2 Apr 2018 16:24:34 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Mon, 2 Apr 2018 16:24:34 +0000 (UTC) User-Agent: Mutt/1.7.2 (2016-11-26) Cc: Johan =?iso-8859-1?Q?Bockg=E5rd?= , emacs-devel@gnu.org To: Stefan Monnier Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Apr 02 18:24:30 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 1f32Fw-0004Xr-G3 for ged-emacs-devel@m.gmane.org; Mon, 02 Apr 2018 18:24:28 +0200 Original-Received: from localhost ([::1]:46684 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1f32I0-0001BQ-2F for ged-emacs-devel@m.gmane.org; Mon, 02 Apr 2018 12:26:36 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:53294) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1f32Hu-0001B4-2P for emacs-devel@gnu.org; Mon, 02 Apr 2018 12:26:31 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1f32Hq-0000bz-Dg for emacs-devel@gnu.org; Mon, 02 Apr 2018 12:26:29 -0400 Original-Received: from colin.muc.de ([193.149.48.1]:21800 helo=mail.muc.de) by eggs.gnu.org with smtp (Exim 4.71) (envelope-from ) id 1f32Hq-0000Q9-1I for emacs-devel@gnu.org; Mon, 02 Apr 2018 12:26:26 -0400 Original-Received: (qmail 6034 invoked by uid 3782); 2 Apr 2018 16:26:21 -0000 Original-Received: from acm.muc.de (p5B1477DA.dip0.t-ipconnect.de [91.20.119.218]) by colin.muc.de (tmda-ofmipd) with ESMTP; Mon, 02 Apr 2018 18:26:19 +0200 Original-Received: (qmail 17818 invoked by uid 1000); 2 Apr 2018 16:25:57 -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:224249 Archived-At: Hello, Stefan. On Fri, Mar 30, 2018 at 09:04:06 -0400, Stefan Monnier wrote: > > But the `(apply ...)' forms are a problem for exactly these other > > things. It's too powerful. The packages that manipulate buffer-undo-list > > can't (and don't try to) handle `apply' properly, since it can contain > > arbitrary effects. > AFAIK the (apply ...) has the needed constraints for undo-in-region to > handle it properly. If not, we should fix it. Indeed we should. undo-elt-in-region "Determine whether UNDO-ELT falls inside the region START ... END." lacks a cond arm for (apply ...), so always returns nil for it, which means that undo doesn't work at all for an (apply ...) element when transient-mark-mode is enabled and the mark is "active" (which is quite common). > So, AFAIK it's handled properly by undo itself, undo-tree, and > undo-in-region. Which "package that manipulate buffer-undo-list" are > you thinking of? Actually, undo-in-region is problematic. Aside from undo-elt-in-region (see above), which is easy to fix, there is undo-adjust-elt "Return adjustment of undo element ELT by the undo DELTAS list.", which can't adjust the contents of an (apply ...) element, since it doesn't know the internal structure of each type of (apply ...). In this sense, (apply ...) is indeed too powerful. Fixing this in general would need something like a property on the (apply ...)'s FUN-NAME symbol, whose value would be a function for "returning the adjustment of the matching (apply ...) element". But that is getting crazy. Why do we have undo-in-region at all? It fouls up the simplicity of the undo mechanism. It also seems like a nuisance rather than a feature: If I were using transient-mark-mode, made some buffer changes, and somehow had a small "active" region; if I then start undoing the changes, I would be annoyed if C-x u missed out some undos because they weren't inside that region. I think it would make undo unusable. How about phasing out undo-in-region? We make it optional in Emacs 27.1 (with the default being off), see if anybody complains, then remove it entirely in Emacs 28. undo-in-region is incompatible with (apply ...). I would say that (apply ...) is the more important of the two. > Stefan -- Alan Mackenzie (Nuremberg, Germany).