From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Morgon Kanter Newsgroups: gmane.emacs.bugs Subject: bug#66998: 29.1; Regression for recursive keyboard macros + minibuffers in (I think) Emacs 28 Date: Sun, 12 Nov 2023 13:26:13 -0500 Message-ID: References: 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="13248"; mail-complaints-to="usenet@ciao.gmane.io" Cc: eliz@gnu.org, 66998@debbugs.gnu.org To: Alan Mackenzie Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Mon Nov 13 04:12:47 2023 Return-path: Envelope-to: geb-bug-gnu-emacs@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 1r2NNX-0003B9-3F for geb-bug-gnu-emacs@m.gmane-mx.org; Mon, 13 Nov 2023 04:12:47 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1r2NNA-00017z-3z; Sun, 12 Nov 2023 22:12:24 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1r2NN8-00015s-Fm for bug-gnu-emacs@gnu.org; Sun, 12 Nov 2023 22:12:22 -0500 Original-Received: from debbugs.gnu.org ([2001:470:142:5::43]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1r2NN7-0000xe-Rm for bug-gnu-emacs@gnu.org; Sun, 12 Nov 2023 22:12:21 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1r2NNn-0008FE-3w for bug-gnu-emacs@gnu.org; Sun, 12 Nov 2023 22:13:03 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Morgon Kanter Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 13 Nov 2023 03:13:03 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 66998 X-GNU-PR-Package: emacs Original-Received: via spool by 66998-submit@debbugs.gnu.org id=B66998.169984517731659 (code B ref 66998); Mon, 13 Nov 2023 03:13:03 +0000 Original-Received: (at 66998) by debbugs.gnu.org; 13 Nov 2023 03:12:57 +0000 Original-Received: from localhost ([127.0.0.1]:57270 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1r2NNc-0008ET-Kn for submit@debbugs.gnu.org; Sun, 12 Nov 2023 22:12:57 -0500 Original-Received: from mail-ot1-x32a.google.com ([2607:f8b0:4864:20::32a]:56348) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1r2FAu-0005gL-0g for 66998@debbugs.gnu.org; Sun, 12 Nov 2023 13:27:15 -0500 Original-Received: by mail-ot1-x32a.google.com with SMTP id 46e09a7af769-6cf65093780so2280335a34.0 for <66998@debbugs.gnu.org>; Sun, 12 Nov 2023 10:26:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1699813585; x=1700418385; darn=debbugs.gnu.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=iNHaOJBqNTCI14rAHVIpf5rqlbcbAfPBoB3eZvqxYFM=; b=kSbSIclPGeBkS/as9qlEslBe3nOoI4ZrXLUHbt6AjB5pRy4i0f2DUi0jwVDoxjdkXb Wney2cI/TKrd7t8EC8u3SuaBsONRVg/9MQVU1EaLjrgswiVpA/UCbFPtfa1nLilrF3sB fDGIOLvbgfFkN+He+Nxd6Rh49gLc/dzPZOFtuq4njQ5DozKszvBF80TxvDKNuKKcd1Dh ncSgTmy0axdkwzuEeGmdvlpRFfZEbxLaWPWYsKDVUj1dGgF/HEqinMR1QAUiU3/GdAl9 /2Bq0B3hV6LC4anCN/QRkML5yDUm6OHHwwrcAIvpS+wlPfX9r+4rBAaNuI7sZVh8GYV6 EVxw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1699813585; x=1700418385; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=iNHaOJBqNTCI14rAHVIpf5rqlbcbAfPBoB3eZvqxYFM=; b=TfDOxvC9lGvZV9EiWglMpt1q3AqYzfnz+PDbDhZa35hh2UrZ5fCdpE0XplbmF2YJhE ENIeqkW4mCv+f8Bavq8FnYPtddbQl4AHPia44DnNJzPNab84Pn+QKBStz6DaWUidKB1k atnT9H9Dt36ngsODyV1LYJG/h41lRtoJz+EYKhmYRvCZKxNEfoRC0jDDeSbc4O/VHfLk RJ0YgY5Oium733niHRhTkMHYfPiQl7q8dj30Z3Sn4PhhaHaBw1RYdpeca4jmfLj6jcig 4WTcEGrisW3rpBEWpNXUEt9+Z17lZZLiXgehS75+iqK9D6HzKBJKvVD9+CfmNtkBpaDN vF8Q== X-Gm-Message-State: AOJu0Yyty/SXzXJgX/7/bgrc3DwWuDdQBaQhKjkfg7ZLT21/QSPeOW6O E7T6NZGP0ss99UUAcZwOXoD602CM69oZzcPF X-Google-Smtp-Source: AGHT+IEgvrH/q9vN/POuYyst11IJwElrTkt/hdvl5nKT1GonU7t+aNdeuv6oMVWW4NfDFRgcFNmXprKMWR7yYovngYI= X-Received: by 2002:a05:6871:5289:b0:1d6:cbcd:80f8 with SMTP id hu9-20020a056871528900b001d6cbcd80f8mr7564088oac.54.1699813584982; Sun, 12 Nov 2023 10:26:24 -0800 (PST) In-Reply-To: X-Mailman-Approved-At: Sun, 12 Nov 2023 22:12:50 -0500 X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.bugs:274244 Archived-At: > > Your intuition was totally right. This isn't really a bug, and > > probably not a regression in behavior either. Use of C-M-c to exit the > > recursive edit before the minibuffer works as expected. The only > > "problem" is that you need to press C-M-c to terminate the minibuffer, > > rather than RET. That's a bit awkward and weird, but it's livable. I > > could probably temporarily rebind RET to make it more ergonomic. But > > the truth is that from Emacs's perspective this isn't even something > > that *should* be fixed -- you *should* be exiting the recursive edit > > before you exit the minibuffer, in that order! > > It should be possible in Emacs to do what you want to do. I've not been > able to come up with any clean way to do this, even after sleeping on > it. > > It seems there is a deficiency in Emacs's keyboard macro handling. I > think we need a new interactive command called something like > interpolate-kbd-macro, which would take one argument, a function to run. > This function would take no arguments and return a list of key > sequences. These key sequences, rather than being inserted into the > keyboard macro, would instead be looked up in the current keymaps, and > their commands (e.g. self-insert-command) would get run as part of the > current keyboard macro invocation. > > Or something like that. What do you think? I ended up advising recursive-edit. I set up a transient keymap that remaps anything that calls minibuffer-exit to exit-recursive-edit. Then the advice, which fires after recursive-edit completes, undoes the transient keymap. As far as I can tell, this works out pretty well. Your idea does sound cleaner overall than my solution. It's worth thinking if there's anything else that would be interesting for enhancing keyboard macros and what's the most general thing we can do as well. Personally the largest issue I had, which I wasn't able to completely solve, was keeping things local to a given kmacro. There's no way I can tell to have some kind of local state for a kmacro. So the most useful enhancement for me, I think, would be to have some kind of explicitly local-to-kmacro variable. I imagine just some specially named variable that could be set when the kmacro is defined, and referenced when the kmacro is running. So if you wanted to you could even turn it into an obarray and have a kmacro-local namespace. > > So this, at least, is WAI and this bug should be closed. > > WAI? That's a new one on me! > > Possibly a new bug should be opened to implement my suggestion above. For reference, here's what I ended up doing with the advice: https://pastebin.com/wG9L7xRb Cheers, -- Morgon