From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Campbell Barton Newsgroups: gmane.emacs.devel Subject: Re: Support for undo-amalgamate in a version of the atomic-change-group macro (with patch) Date: Tue, 2 Nov 2021 13:14:21 +1100 Message-ID: References: <2d2efa59-cf88-5238-0db6-58d55e6c5c98@gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="38894"; mail-complaints-to="usenet@ciao.gmane.io" Cc: Stefan Monnier To: Emacs developers Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Tue Nov 02 03:19:13 2021 Return-path: Envelope-to: ged-emacs-devel@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1mhjOL-0009w7-0q for ged-emacs-devel@m.gmane-mx.org; Tue, 02 Nov 2021 03:19:13 +0100 Original-Received: from localhost ([::1]:49306 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1mhjOJ-0000Yx-Rn for ged-emacs-devel@m.gmane-mx.org; Mon, 01 Nov 2021 22:19:11 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:51490) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mhjJt-0005Sl-Ov for emacs-devel@gnu.org; Mon, 01 Nov 2021 22:14:37 -0400 Original-Received: from mail-pf1-x432.google.com ([2607:f8b0:4864:20::432]:45014) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1mhjJq-0006ON-QP for emacs-devel@gnu.org; Mon, 01 Nov 2021 22:14:36 -0400 Original-Received: by mail-pf1-x432.google.com with SMTP id k2so3527530pff.11 for ; Mon, 01 Nov 2021 19:14:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=dGdkvnfljI9IyV4Q0HbUSpJ+vNocaxly5ZjwhRjGzd0=; b=XfYtEiUHVhzC0lrX8fwR7bb+krRQzAh8KmTRblTcJYbkdFKV76FKmNw5FyeimP7+CX LuAihiQReEffDC3Ze6dETrrrc19WfG8T2U1yQxhl30hYzt4mjTu7R8ADD1mhXoyhD2Cj E69HWaar+9ko3o8cAb+kG456J7+Wp/DQN+cjXFNHgeR+XiBgYdXDJUJ7xqQ0QMrtYYhP AtmHFgyva5NhSzM2Jo1c8JzeKm6eB5ME7vzkAxUVZqntiDhTONjqK7DQ3dTYVanbvqRo lpL/zK4S/5DsPPcKh7xZIyHR/CHd7CcUjy+2Hx45cKuylrNYaevIqh9fl0BkAaCHKoVc Nffg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=dGdkvnfljI9IyV4Q0HbUSpJ+vNocaxly5ZjwhRjGzd0=; b=efvPzThMXB16PtFayLzH+4NP0bZGmnpgDdYCw7eqeUajIDnBQnMaOpWkU833eY4q+4 nBPryyvfFEOVZtUY308M4/Hq5aa0Ud9xqF5fZ4X53GvfmV7m4heBA+iBcDwrDI0KHyDT tS3VFB1vcriGAhStZW0D5NCV6siJfZEDZugAcUyM7jWedfLxZyAUKY9UHw3meks6uYIP GrgDcmvRPZXNImzPxsox9QKlB3Yxma0chAzHXpkTm6Yabzg4MZELZOijTesRalcrgwW5 LbRpwekwgRqjHKr86leen2WyTYwBqvXNw8jWTEGQBJoOYAiALEJ9RKW/vMK6e/iuGcUk AZ7w== X-Gm-Message-State: AOAM532/D+uTLVjJafwaSo6tp/dldpaOdToIPRGphqPBkFF6tkt+JhU3 Tpcr8+k4A7otAmspi3Sejs3mrLt1evD8AnxdPR68Dy1B7MU= X-Google-Smtp-Source: ABdhPJynzePTErm1bb0jY/ZBgThPgO48kHR3SslhryzbGD36pCtfvt7+xsCO1hH9bMmEkwhKImOgt0FAVhfSVx9v4KA= X-Received: by 2002:a65:6792:: with SMTP id e18mr9133758pgr.318.1635819273069; Mon, 01 Nov 2021 19:14:33 -0700 (PDT) In-Reply-To: <2d2efa59-cf88-5238-0db6-58d55e6c5c98@gmail.com> Received-SPF: pass client-ip=2607:f8b0:4864:20::432; envelope-from=ideasman42@gmail.com; helo=mail-pf1-x432.google.com X-Spam_score_int: -17 X-Spam_score: -1.8 X-Spam_bar: - X-Spam_report: (-1.8 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.29 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-mx.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.io gmane.emacs.devel:278459 Archived-At: On Tue, Nov 2, 2021 at 12:04 PM Campbell Barton wrote: > > On 11/2/21 04:43, Stefan Monnier wrote: > >> Hi, there have been a handful of times I've needed to treat multiple > >> actions as a single action, > >> others too (see stackoverflow question [0]). > >> > >> While this is supported using change groups, the resulting macro ends > >> up being nearly identical to the existing `atomic-change-group' macro. > >> The only difference is a call to undo-amalgamate-change-group. > > > > The other difference would be the call to `cancel-change-group` (you > > may want to not undo the changes in case of errors). > > Good point (updated my answer) > > >> Attached a patch to add `atomic-change-group-undo-amalgamate' so > >> packages don't need to use a modified copy of this macro. > > > > I suspect that we'd be better off with a separate macro which only does > > the amalgamation without the cancel-change-group-on-error. > > Agree, if the cancel group is removed it's no longer atomic and can be a > separate macro. > > > But I wonder how often such a macro would be useful: undo boundaries are > > normally added only by the command-loop (i.e. the loop which repeatedly > > reads a key and calls the corresponding command), so unless your macro's > > body calls `recursive-edit` it's very unlikely that you'll get any undo > > entries that you would then want to remove. > > I'm not sure why most other people are running into this (the original > question relates specifically voice commands), nevertheless the stats on > the stackexchange question lead me to think it's not so unusual to spawn > multiple commands that happen to be treated as separate undo steps. > > > (Re)reading your stackexchange question, it seems you want to amalgamate > > undo entries from different commands. So do you run those commands > > within a `recursive-edit`? If not, how do you manage to run those > > commands from within your (new) macro? > > As far as I know I'm not using recursive edit (unless indirectly). > > In these situations collapsing undo data was necessary. > > - Calling kmacro-exec-ring-item (based on this answer [0]) > - Calling some evil functions for e.g. > > (defun evil-paste-and-indent-after () > (interactive) > (with-undo-collapse > (evil-paste-after 1) > (evil-indent (evil-get-marker ?\[) > (evil-get-marker ?\])))) > > [0]: https://emacs.stackexchange.com/questions/70 To follow up on my previous post, from checking packages on melpa, the following use an undo-collapse macro: - recomplete (recomplete--with-undo-collapse) - jupyter (jupyter-repl-with-single-undo) - meow (meow--wrap-collapse-undo) - symex (symex--with-undo-collapse) Candidates which could potentially use an undo collapse macro but mix undo-amalgamate with other logic: - eglot (eglot--apply-text-edits) - lsp-mode (lsp--apply-text-edits) - parinfer-rust-mode (parinfer-rust--execute)