From unknown Fri Aug 08 22:13:29 2025 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Mailer: MIME-tools 5.509 (Entity 5.509) Content-Type: text/plain; charset=utf-8 From: bug#61176 <61176@debbugs.gnu.org> To: bug#61176 <61176@debbugs.gnu.org> Subject: Status: post-command-hook is not run if minibuffer input is aborted Reply-To: bug#61176 <61176@debbugs.gnu.org> Date: Sat, 09 Aug 2025 05:13:29 +0000 retitle 61176 post-command-hook is not run if minibuffer input is aborted reassign 61176 emacs submitter 61176 Jonas Bernoulli severity 61176 normal thanks From debbugs-submit-bounces@debbugs.gnu.org Mon Jan 30 10:07:47 2023 Received: (at submit) by debbugs.gnu.org; 30 Jan 2023 15:07:47 +0000 Received: from localhost ([127.0.0.1]:50082 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pMVl4-0006fa-Li for submit@debbugs.gnu.org; Mon, 30 Jan 2023 10:07:47 -0500 Received: from lists.gnu.org ([209.51.188.17]:47028) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pMVl3-0006fS-1h for submit@debbugs.gnu.org; Mon, 30 Jan 2023 10:07:45 -0500 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 1pMVl1-0006W5-Em for bug-gnu-emacs@gnu.org; Mon, 30 Jan 2023 10:07:43 -0500 Received: from mail.hostpark.net ([212.243.197.30]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1pMVkv-0003LV-0Q for bug-gnu-emacs@gnu.org; Mon, 30 Jan 2023 10:07:38 -0500 Received: from localhost (localhost [127.0.0.1]) by mail.hostpark.net (Postfix) with ESMTP id C5F611625E for ; Mon, 30 Jan 2023 16:07:32 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=bernoul.li; h= content-transfer-encoding:content-type:content-type:mime-version :message-id:date:date:subject:subject:from:from:received :received; s=sel2011a; t=1675091252; bh=xm8mU2aFUjHiR8tVFx7pZjAx 7BqTANmqH7awNFrRWdc=; b=RnchppOXBEDK6h5Wpik69AKGNVJqWcrfOhNUNsMW opOD3jFfjEJZFvoZ+6KPQDQ4E1MxebI8rJIqllDln8f6oUwp5lSL09UudDQEZOW3 vWh0onZBgeeWfstqd7ylLgXVQnhKBL6iQclg0zs6VEV9egJiZz+MOdt124ClG5nn 6oI= X-Virus-Scanned: by Hostpark/NetZone Mailprotection at hostpark.net Received: from mail.hostpark.net ([127.0.0.1]) by localhost (mail1.hostpark.net [127.0.0.1]) (amavisd-new, port 10224) with ESMTP id UTqG6mhsipxH for ; Mon, 30 Jan 2023 16:07:32 +0100 (CET) Received: from customer (localhost [127.0.0.1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-256) server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by mail.hostpark.net (Postfix) with ESMTPSA id 8442F1625C for ; Mon, 30 Jan 2023 16:07:32 +0100 (CET) From: Jonas Bernoulli To: bug-gnu-emacs@gnu.org Subject: post-command-hook is not run if minibuffer input is aborted Date: Mon, 30 Jan 2023 16:07:30 +0100 Message-ID: <87y1pk2h8t.fsf@bernoul.li> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Received-SPF: none client-ip=212.243.197.30; envelope-from=jonas@bernoul.li; helo=mail.hostpark.net X-Spam_score_int: -27 X-Spam_score: -2.8 X-Spam_bar: -- X-Spam_report: (-2.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, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: submit X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > -- Variable: post-command-hook > This normal hook is run by the editor command loop after it > executes each command (including commands terminated prematurely by > quitting or by errors). At that time, =E2=80=98this-command=E2=80=99= refers to the > command that just ran, and =E2=80=98last-command=E2=80=99 refers to t= he command > before that. > > This hook is also run when Emacs first enters the command loop (at > which point =E2=80=98this-command=E2=80=99 and =E2=80=98last-command= =E2=80=99 are both =E2=80=98nil=E2=80=99). - post-command-hook is run even if a command is "terminated prematurely by quitting or by errors". This is very useful when it is crucial that some cleanup is run even when something goes wrong. - When a command uses the minibuffer, then post-command-hook is additionally run when the minibuffer is setup, with this-command being the command that uses the minibuffer. This happens before minibuffer-setup-hook is run. This is surprising, because undocumented, but easy to detect, because at this time this-command-keys-vector returns an empty vector. Never- the-less this should be documented (instead of being "fixed"; I depend on this behavior, and so might others). - However, when the command reads from the minibuffer and the user aborts that, then post-command-hook is NOT run a second time AFTER the command. This is extremely inconvenient. IMO, the fact that this hook is documented to run even if the command "terminated prematurely by quitting or by errors", implies that the hook is run even if the quitting is done intentionally by the user. This could be fixed simply by running post-command-hook in this case as well. If that is considered a dangerous change in behavior, then maybe a very similar hook --say unwind-command-hook-- could be added. Cheers, Jonas Oh -- here's some code that can be used to observe this behavior: (keymap-global-set "" '-command) (keymap-global-set "" '-prepare) (keymap-global-set "" '-cleanup) (defun -prepare () (interactive) (add-hook 'post-command-hook '-post) (add-hook 'minibuffer-setup-hook '-setup) (add-hook 'minibuffer-exit-hook '-exit)) (defun -cleanup () (interactive) (remove-hook 'post-command-hook '-post) (remove-hook 'minibuffer-setup-hook '-setup) (remove-hook 'minibuffer-exit-hook '-exit)) (defun -post () (message ";; -post (%-10s %s)" (this-command-keys-vector) this-command= )) (defun -setup () (message ";; -setup (%-10s %s)" (this-command-keys-vector) this-command= )) (defun -exit () (message ";; -exit (%-10s %s)" (this-command-keys-vector) this-command= )) (defun -command () (interactive) (message ";; -command")) ;; -command ;; -post ([f1] -command) (defun -command () (interactive) (message ";; -command") (error "error in command")) ;; -command ;; -command: error in command ;; -post ([] -command) (defun -command () (interactive (error "error in interactive")) (message ";; -command")) ;; call-interactively: error in interactive ;; -post ([] -command) (defun -command (arg) (interactive (list (read-string ": "))) (message ";; -command")) ;; -setup ([f1] -command) ;; -post ([] -command) ;; -post ([97] self-insert-command) ;; -exit ([return] exit-minibuffer) ;; -command ;; -post ([f1] -command) ;; -setup ([f1] -command) ;; -post ([] -command) ;; -exit ([7] abort-minibuffers) ;; Quit ;; -post ([] abort-minibuffers) (defun -command () (interactive) (message ";; -command") (read-string "-command: ")) ;; -setup ([f1] -command) ;; -post ([] -command) ;; -post ([97] self-insert-command) ;; -exit ([return] exit-minibuffer) ;; -post ([f1] exit-minibuffer) ;; -setup ([f1] -command) ;; -post ([] -command) ;; -exit ([return] exit-minibuffer) ;; -post ([f1] exit-minibuffer) (defun -command (arg) (interactive (list (read-from-minibuffer ": " nil (let ((map (make-sparse-keymap))) (set-keymap-parent map minibuffer-local-map) (define-key map "a" (lambda () (interactive) (error "error in minibuffer"))) map)))) (message ";; -command")) ;; -setup ([f1] -command) ;; -post ([] -command) ;; (lambda nil (interactive) (error error in minibuffer)): error in minibuf= fer ;; -post ([] (lambda nil (interactive) (error error in minibuffe= r))) ;; -exit ([return] exit-minibuffer) ;; -command ;; -post ([f1] -command) From debbugs-submit-bounces@debbugs.gnu.org Wed Feb 01 18:06:41 2023 Received: (at 61176) by debbugs.gnu.org; 1 Feb 2023 23:06:41 +0000 Received: from localhost ([127.0.0.1]:60091 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pNMBd-0005kU-71 for submit@debbugs.gnu.org; Wed, 01 Feb 2023 18:06:41 -0500 Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:25366) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pNMBZ-0005kA-83 for 61176@debbugs.gnu.org; Wed, 01 Feb 2023 18:06:39 -0500 Received: from pmg1.iro.umontreal.ca (localhost.localdomain [127.0.0.1]) by pmg1.iro.umontreal.ca (Proxmox) with ESMTP id 2247B1000D2; Wed, 1 Feb 2023 18:06:30 -0500 (EST) Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1]) by pmg1.iro.umontreal.ca (Proxmox) with ESMTP id 0C64F1000CC; Wed, 1 Feb 2023 18:06:28 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca; s=mail; t=1675292788; bh=FIxlNumDkqwPrOBCdQq46BtbqMdWELE2D6WSHRC/fCQ=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=E4POoj7AhIl5PHbwylkcKcw26tkShfDwB3q55DCM9z9tkHxKAlSNGyoT0f89zLmES h57FvIndWrPyH281zm5n32uuLsRouQb2nCdOEJwRJxj5+7x2PmnxEQzqRBSK5DUJ8+ cMYEa3uHIfxN0JBI6u4W1MQQRoKO8NXt5Wk3fdJ4Ar5teFeLVmLBbz4DHLZsVzw4aV M7UmVh6hGM3atfEKT5RqbrnfcWB5UAWilgOYXB1aTdo+xrcM5NbldUHwHyb/SDokGB f67uuETKIrbQt2BQznVokplnGqzc+mSJWCE4+4rA6iI4TyenIv/cZWloQPfEY4yI0S u+kAky9IrPcUg== Received: from lechazo (lechon.iro.umontreal.ca [132.204.27.242]) by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id F08A5120E61; Wed, 1 Feb 2023 18:06:27 -0500 (EST) From: Stefan Monnier To: Jonas Bernoulli Subject: Re: bug#61176: post-command-hook is not run if minibuffer input is aborted In-Reply-To: <87y1pk2h8t.fsf@bernoul.li> (Jonas Bernoulli's message of "Mon, 30 Jan 2023 16:07:30 +0100") Message-ID: References: <87y1pk2h8t.fsf@bernoul.li> Date: Wed, 01 Feb 2023 18:06:24 -0500 User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain X-SPAM-INFO: Spam detection results: 0 ALL_TRUSTED -1 Passed through trusted hosts only via SMTP AWL -0.029 Adjusted score from AWL reputation of From: address BAYES_00 -1.9 Bayes spam probability is 0 to 1% DKIM_SIGNED 0.1 Message has a DKIM or DK signature, not necessarily valid DKIM_VALID -0.1 Message has at least one valid DKIM or DK signature DKIM_VALID_AU -0.1 Message has a valid DKIM or DK signature from author's domain X-SPAM-LEVEL: X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 61176 Cc: 61176@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > - However, when the command reads from the minibuffer and the user > aborts that, then post-command-hook is NOT run a second time AFTER > the command. Could you clarify what you mean here? Let's say in the following scenario: - The user hits a key like `M-x` which causes a minibuffer to be entered. - the user hits C-g. - Emacs exits the minibuffer and doesn't even call the command because the interactive args could not be gathered. When do you expect `post-command-hook` to be run? There's also the case where the command is called and it enters the minibuffer (rather than doing it within the interactive spec). Not sure if it makes a significant difference. Also it would help to know what you need `post-command-hook` for. [ There are several "alternatives" to `post-command-hook` plus there are cases where code is executed not via a command, yet it can be viewed as a command execution as well (e.g. opening a file via `emacsclient`), so over the years ad-hoc calls to `post-command-hook` have been sprinkled outside of the "command-loop", which makes this whole business even more muddy. ] Stefan From debbugs-submit-bounces@debbugs.gnu.org Thu Feb 02 09:36:20 2023 Received: (at 61176) by debbugs.gnu.org; 2 Feb 2023 14:36:20 +0000 Received: from localhost ([127.0.0.1]:33001 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pNahI-000422-6r for submit@debbugs.gnu.org; Thu, 02 Feb 2023 09:36:20 -0500 Received: from mail.hostpark.net ([212.243.197.30]:37448) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pNahG-00041t-4F for 61176@debbugs.gnu.org; Thu, 02 Feb 2023 09:36:19 -0500 Received: from localhost (localhost [127.0.0.1]) by mail.hostpark.net (Postfix) with ESMTP id BF657167E0; Thu, 2 Feb 2023 15:36:15 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=bernoul.li; h= content-type:content-type:mime-version:message-id:date:date :references:in-reply-to:subject:subject:from:from:received :received; s=sel2011a; t=1675348575; bh=XzbCabR5Fslcbqt5vYa2Kz8u WmRv7F6dAfQMoC14v4I=; b=TY1jHPmSAJcdr/reR0W7ZNA9Wq8FtVFIEL5z3sCU uhrm31z0mKIqfj0UlSVEQ7BUVQ2pb+YREfj45G5ezIfBq58cAGBJKd3lJVs6y8IA mrWk/hmFl+ug8WfKywl4m0iR8K+JP/9OC9MN6setwVlUekHOPWelSwuuwKFhyF5j oyU= X-Virus-Scanned: by Hostpark/NetZone Mailprotection at hostpark.net Received: from mail.hostpark.net ([127.0.0.1]) by localhost (mail1.hostpark.net [127.0.0.1]) (amavisd-new, port 10224) with ESMTP id 9vW2fgu3xlFB; Thu, 2 Feb 2023 15:36:15 +0100 (CET) Received: from customer (localhost [127.0.0.1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-256) server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by mail.hostpark.net (Postfix) with ESMTPSA id 8C00016782; Thu, 2 Feb 2023 15:36:15 +0100 (CET) From: Jonas Bernoulli To: Stefan Monnier Subject: Re: bug#61176: post-command-hook is not run if minibuffer input is aborted In-Reply-To: References: <87y1pk2h8t.fsf@bernoul.li> Date: Thu, 02 Feb 2023 15:36:15 +0100 Message-ID: <87sffojfs0.fsf@bernoul.li> MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 61176 Cc: 61176@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.7 (-) Stefan Monnier writes: >> - However, when the command reads from the minibuffer and the user >> aborts that, then post-command-hook is NOT run a second time AFTER >> the command. > > Could you clarify what you mean here? > Let's say in the following scenario: > > - The user hits a key like `M-x` which causes a minibuffer to be entered. > - the user hits C-g. > - Emacs exits the minibuffer and doesn't even call the command because > the interactive args could not be gathered. > > When do you expect `post-command-hook` to be run? Going back to the examples I provided, if the user does NOT abort, then this happens: >> ;; -setup ([f1] -command) >> ;; -post ([] -command) >> ;; -post ([97] self-insert-command) >> ;; -exit ([return] exit-minibuffer) >> ;; -command >> ;; -post ([f1] -command) And if the user DOES abort, I would like the behavior to be changed like so: >> ;; -setup ([f1] -command) >> ;; -post ([] -command) >> ;; -exit ([7] abort-minibuffers) >> ;; Quit >> ;; -post ([] abort-minibuffers) *NEW* -post ([f1] -command) > There's also the case where the command is called and it enters the > minibuffer (rather than doing it within the interactive spec). Not sure > if it makes a significant difference. The sequence of events is the same as in the above case. I posted the wrong log in the examples I provided. I posted two instances of the user not aborting instead providing the output for when they abort, which is: >> ;; -command >> ;; -setup ([f1] -command) >> ;; -post ([] -command) >> ;; -exit ([7] abort-minibuffers) >> ;; Quit >> ;; -post ([] abort-minibuffers) So it seems that iff a command uses the minibuffer, then post-command-hook is ALWAYS run for it right before the minibuffer is entered, regardless of where the recursive edit is entered; and iff the user aborts the minibuffer, then the post-command-hook is NEVER run "after"/"post" the outer command. > Also it would help to know what you need `post-command-hook` for. This is relevant for the Transient package. The following is a simplified description of relevant parts of what it does. Calling a transient prefix command installs a transient keymap and adds functions to `pre-command-hook' and `post-command-hook'. The pre-command function is responsible for determining whether a subsequently called (suffix) command should exit the transient state. If we are about to exit the transient, then this does also set some global variables to nil, which are only relevant while the transient is still active. However, it does not and cannot unset all variables and most importantly it does not remove the transient keymap and the pre- and post-command functions. This function may (or may not) set other global variables, so that the command that is about to be called has access to the arguments set in the transient command. This is similar to how prefix arguments are implemented. However, if I remember correctly, in the case of prefix arguments, there is some C code that takes care of unsetting the prefix argument, if the next command is aborted. Transient on the other hand has to do that in Elisp, and it used the post-command-hook for that (among other things). Then the command's interactive spec is processed and then the command is called with the arguments thus determined. Once that is done, then the post-command function is called. It is responsible for redisplaying the transient buffer that displays the available suffix commands. Or if the suffix command should exit the transient, then it has to remove the transient map and the pre- and post functions, and unset the variables that serve a similar role to prefix-arg, as well as some internal variables. The suffix command may use the minibuffer inside interactive and/or in its body. If that happens, then transient has to suspend the transient keymap and pre- and post-command functions, while the minibuffer is in use. There are two kinds of suffix commands that may (or may not) use the minibuffer: (1) Commands that are specifically designed to be used to set the value of some argument in the transient command. These commands are fully under our control and are designed to handle the suspension and resuming of the transient map and the pre- and post-command hooks, using minibuffer-setup-hook, minibuffer-exit-hook, and unwind-protect. (2) Arbitrary commands, which may have been written with Transient in mind, but which more likely do nothing to account for the needs of Transient, i.e., any command that exists in Emacs. When a (2) command is invoked and that uses the minibuffer, then our post-command function detects that because it is called with this-command being the suffix command and this-command-keys-vector being an empty vector. The transient map and pre- and post-command hooks are then suspended like when a (1) command uses the minibuffer, but it is not possible to use unwind-protect to ensure that these things are reinstated (or the transient is fully exited), even if the user aborts while the minibuffer is active. If post-command-hook were run ("post" command) regardless of whether the user aborts the minibuffer, then such aborts would not have to be handled specifically. Since that is not the case, the pre-mature invocation of the post-command function, has to delay the resume-or-exit work until some other event occurs. Currently that is being done by adding a new minibuffer-exit function and *another* post-command function. The first is designed perform the resume/exit behavior if the minibuffer is aborted, and the second function is designed to perform the resume/exit behavior if the first function did not end up doing that, i.e., if the minibuffer was not aborted. This is fragile. Heuristics have to be used to determine whether the minibuffer is exited normally or if it was aborted. (There is only minibuffer-exit-hook, and as far as I can tell, there is no reliable way to determine whether that was called because the minibuffer was exited normally or was aborted.) This approach works more or less, but a few times I already though I had finally tweaked it enough to handle all edge-cases, only to later learn that was not so. Currently there is one case where it doesn't work as intended. And if a third-party completion framework were used that exits the minibuffer in some highly unexpected way then it would also not work (but currently no such framework does that, I believe)). > [ There are several "alternatives" to `post-command-hook` plus there > are cases where code is executed not via a command, yet it can be > viewed as a command execution as well (e.g. opening a file via > `emacsclient`), so over the years ad-hoc calls to `post-command-hook` > have been sprinkled outside of the "command-loop", which makes this > whole business even more muddy. ] What alternatives are you thinking about? Piuu, that got a bit long. I left out details, but I hope it became clear why I need the post-command-hook to always be run *post* command (and that that is a legitimate need). > - The user hits a key like `M-x` which causes a minibuffer to be entered. > - the user hits C-g. > - Emacs exits the minibuffer and doesn't even call the command because > the interactive args could not be gathered. That could be used as an argument as to why post-command-hook should not be run when the interactive minibuffer is aborted: if we never go "inside" the command, there also is no point in going "post" command. However, it does not appear that this is actually the reason why post-command-hook is not being run "post" command, not from a design perspective at least. If the user aborts the minibuffer usage of the following command, which uses the minibuffer in its body, then the post-command-hook also isn't being run "post" command, even though we clearly made it "into" the command: >> (defun -command () >> (interactive) >> (message ";; -command") >> (read-string "-command: ")) >> >> ;; -command >> ;; -setup ([f1] -command) >> ;; -post ([] -command) >> ;; -exit ([7] abort-minibuffers) >> ;; Quit >> ;; -post ([] abort-minibuffers) Thanks for looking into this! Jonas From debbugs-submit-bounces@debbugs.gnu.org Sun Feb 05 09:47:58 2023 Received: (at 61176) by debbugs.gnu.org; 5 Feb 2023 14:47:58 +0000 Received: from localhost ([127.0.0.1]:44460 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pOgJB-0001cx-MJ for submit@debbugs.gnu.org; Sun, 05 Feb 2023 09:47:58 -0500 Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:42783) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pOgJ9-0001c4-EH for 61176@debbugs.gnu.org; Sun, 05 Feb 2023 09:47:56 -0500 Received: from pmg1.iro.umontreal.ca (localhost.localdomain [127.0.0.1]) by pmg1.iro.umontreal.ca (Proxmox) with ESMTP id 8E30D1000C7; Sun, 5 Feb 2023 09:47:49 -0500 (EST) Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1]) by pmg1.iro.umontreal.ca (Proxmox) with ESMTP id D113F100048; Sun, 5 Feb 2023 09:47:43 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca; s=mail; t=1675608463; bh=Liy96rWQ6QVTXqLxuTnGnXmUDbNaCVpjJIMFOLQDHzA=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=QnZ5ugunue7L4pmK1UxEIaeSG/W7FIdoTFB4VaZi8wvop3MmPAtJrQ69glvMx87mY VTmo+raEj2cPtP92yA66ckW6vECc25aROLzv93ZvG/jzxPeLfs56ZKXg6CqSlNsXBy Zq8ZKFmX/YeoyO9S3eAFogjBarSgHlesWIjAI23BvPvrdfcJ7c5pJIN7xaKmhwg+Kl Xjk5t8kjblgh16OJDQJfnc2FfKfkjy7XtwtgZUDs1BXxShPoxNdKBdAFI8mgYuO3GI bSX7tZ/0NbupIgpUxfZjbv9Wbof1zCyWs15pf23VM/KO12myUM2ZEnMr9uv/RJnWHx 39Cx4noTVM4Ow== Received: from pastel (unknown [104.247.245.112]) by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id A87A1121321; Sun, 5 Feb 2023 09:47:43 -0500 (EST) From: Stefan Monnier To: Jonas Bernoulli Subject: Re: bug#61176: post-command-hook is not run if minibuffer input is aborted In-Reply-To: <87sffojfs0.fsf@bernoul.li> (Jonas Bernoulli's message of "Thu, 02 Feb 2023 15:36:15 +0100") Message-ID: References: <87y1pk2h8t.fsf@bernoul.li> <87sffojfs0.fsf@bernoul.li> Date: Sun, 05 Feb 2023 09:47:42 -0500 User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain X-SPAM-INFO: Spam detection results: 0 ALL_TRUSTED -1 Passed through trusted hosts only via SMTP AWL -0.175 Adjusted score from AWL reputation of From: address BAYES_00 -1.9 Bayes spam probability is 0 to 1% DKIM_SIGNED 0.1 Message has a DKIM or DK signature, not necessarily valid DKIM_VALID -0.1 Message has at least one valid DKIM or DK signature DKIM_VALID_AU -0.1 Message has a valid DKIM or DK signature from author's domain X-SPAM-LEVEL: X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 61176 Cc: 61176@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > And if the user DOES abort, I would like the behavior to be changed like > so: > >>> ;; -setup ([f1] -command) >>> ;; -post ([] -command) >>> ;; -exit ([7] abort-minibuffers) >>> ;; Quit >>> ;; -post ([] abort-minibuffers) > *NEW* -post ([f1] -command) Hmm... fully agreed and I wonder why it's not run. [ The rest of the discussion is largely independent from this. ] > The suffix command may use the minibuffer inside interactive and/or in > its body. If that happens, then transient has to suspend the transient > keymap and pre- and post-command functions, while the minibuffer is in > use. FWIW, I have played with similar issues in the context of prefix commands and `set-transient-map` (yet, can't find the corresponding code, sorry) and I remember using `minibuffer-depth` to detect the use of a minibuffer (i.e. record the original `minibuffer-depth` and/or `recursion-depth` compare it to the current depth in `pre-command-hook`). I see `transient.el` also uses `minibuffer-depth`, so I guess I'm not telling you anything you didn't already know. I also remember considering adding hooks to `read-from-minibuffer` and `recursive-edit` so we can more proactively and reliably let-bind variables around them (e.g. we should let-bind `this-command` around them). Stefan