From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Stefan Monnier via "Bug reports for GNU Emacs, the Swiss army knife of text editors" Newsgroups: gmane.emacs.bugs Subject: bug#65511: [PATCH] copy-next-command-output suggestion Date: Mon, 04 Sep 2023 18:17:44 -0400 Message-ID: References: <87ttsoqfbn.fsf@jeremybryant.net> <83v8d3odvt.fsf@gnu.org> Reply-To: Stefan Monnier Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="30359"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Cc: Jeremy Bryant , 65511@debbugs.gnu.org To: Eli Zaretskii Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Tue Sep 05 00:18:08 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 1qdHtY-0007hh-11 for geb-bug-gnu-emacs@m.gmane-mx.org; Tue, 05 Sep 2023 00:18:08 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1qdHtT-0004Z3-F4; Mon, 04 Sep 2023 18:18:03 -0400 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 1qdHtS-0004Ys-I2 for bug-gnu-emacs@gnu.org; Mon, 04 Sep 2023 18:18:02 -0400 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 1qdHtS-0004gx-A9 for bug-gnu-emacs@gnu.org; Mon, 04 Sep 2023 18:18:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1qdHtS-0004hO-CW for bug-gnu-emacs@gnu.org; Mon, 04 Sep 2023 18:18:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Stefan Monnier Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 04 Sep 2023 22:18:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 65511 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: patch Original-Received: via spool by 65511-submit@debbugs.gnu.org id=B65511.169386588118055 (code B ref 65511); Mon, 04 Sep 2023 22:18:02 +0000 Original-Received: (at 65511) by debbugs.gnu.org; 4 Sep 2023 22:18:01 +0000 Original-Received: from localhost ([127.0.0.1]:52878 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qdHtQ-0004h8-I5 for submit@debbugs.gnu.org; Mon, 04 Sep 2023 18:18:01 -0400 Original-Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:48919) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qdHtN-0004gu-1E for 65511@debbugs.gnu.org; Mon, 04 Sep 2023 18:17:58 -0400 Original-Received: from pmg1.iro.umontreal.ca (localhost.localdomain [127.0.0.1]) by pmg1.iro.umontreal.ca (Proxmox) with ESMTP id 888FF10006B; Mon, 4 Sep 2023 18:17:51 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca; s=mail; t=1693865866; bh=+FQpQEkW7489HEz0sUINXaUgZfMxVICVbIc+AVQXHuk=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=b6Uzn066CQuW03SEUK2Tpn2Gyl0rV0tH8TWziR/T4krat0pWD0l9oqPk/VH2fUE7s CC0UGRSSOTSDvbqJfScYVnQuU8VxAZUBr2Oyk+dfY+r0CH89TRpj88q40nnh4b7FJ5 FZqgRn1ZbxPiLdtcUD8nSReLMKsaHsr2gXau7n8rY4UJ0OlHpDTB7gOiaPTBz+/6aA xwMxklfbbUUCC0FmDRt/9J/6hrlaI+/jIROH/fSEmGdCc82vKraB0JlJVWlhjf6bwI iQyN9/SAcEdxSEUHgchWzuyv4Dymp/docdrGoDKGqpI+HOcq4t7z8JeWEKEKxI/UvL Mf/L0p5V/j65A== Original-Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1]) by pmg1.iro.umontreal.ca (Proxmox) with ESMTP id F32F4100046; Mon, 4 Sep 2023 18:17:45 -0400 (EDT) Original-Received: from pastel (69-165-136-223.dsl.teksavvy.com [69.165.136.223]) by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id B59231201E6; Mon, 4 Sep 2023 18:17:45 -0400 (EDT) In-Reply-To: <83v8d3odvt.fsf@gnu.org> (Eli Zaretskii's message of "Fri, 25 Aug 2023 09:05:42 +0300") 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:269316 Archived-At: > Reading the code, I'm worried by adding/removing hooks without > suitable unwind-protect protection: what if some code signals an error > or the user hits C-g before this code runs to completion? We need to > make sure these hooks are cleaned up properly in those cases. This is a prefix command, like `C-u`, `C-x 8 u`, and a few more: it runs to completion before it does anything useful, since its mode of operation is to arrange for the next command to be run slightly differently. The way it tries to make sure to disable itself "soon" is to use `pre/post-command-hooks` in a way that should hopefully ensure it won't linger longer than desired. It's not as definite as I'd like either, but it's the best way I could come up with so far. I think that if we want to make it better, then we should seriously look at improving our command-loop to provide better built-in support for prefix commands. The patch below includes a longer comment explaining the various possible states,, which should hopefully help convince oneself that it should work acceptably. > I also wonder whether we should bind interprogram-cut-function to nil > around the call to kill-new, since this stuff probably should be put > in the clipboard, right? I don't understand: binding it to nil would *prevent* it from making it to the clipboard, whereas I don't see why we shouldn't obey `select-enable-clipboard` and `select-enable-primary` here. > Also, what happens if some process-filter or process-sentinel or timer > fire during the time these hooks are in effect: will the stuff added > to the kill-ring include their output as well? Yes. Not sure we should try to do something about it. > And finally, this feature only works with commands whose output goes > to *Messages*, right? Yup. > If so, there are commands which show messages in other ways, and at > the very least the doc string should mention that caveat. > Bonus points for adding ways of capturing those other kinds of output > as well. Agreed. BTW, the reason why I haven't pushed to include it in Emacs is that I'm not really satisfied with the UI: in most cases I don't know beforehand that I want to capture a command's output, so a "postfix command" (i.e. one we can run after the fact) would be much preferable. It might not be that hard to do: tho: just push markers in *Messages* at the beginning/end of every command (unless there have been no messages since the last push), make sure we throw away those markers that reach `point-min`, and then add a `copy-last-command-output` command that uses those markers to extract the last message using those markers. The tricky part will be to find the right message when messages are emitted (e.g. by the completion UI) while the user types `M-x copy-last-command-output RET`. Stefan diff --git a/doc/emacs/screen.texi b/doc/emacs/screen.texi index 5e9e89e6b11..4e65bc1105f 100644 --- a/doc/emacs/screen.texi +++ b/doc/emacs/screen.texi @@ -146,6 +146,11 @@ Echo Area this limit, one line is deleted from the beginning whenever a new message line is added at the end. +@cindex{copy-next-command-output} + You can also capture the messages of a command by running the +command @code{copy-next-command-output} beforehand, which will put them +in the kill ring. + @xref{Display Custom}, for options that control how Emacs uses the echo area. diff --git a/etc/NEWS b/etc/NEWS index fbb13254e64..d5bd372ecfb 100644 --- a/etc/NEWS +++ b/etc/NEWS @@ -162,6 +162,8 @@ displayed on the mode line when 'appt-display-mode-line' is non-nil. * Editing Changes in Emacs 30.1 +** New command 'copy-next-command-output' to capture echo area messages + --- ** New global minor mode 'kill-ring-deindent-mode'. When enabled, text being saved to the kill ring will be de-indented by diff --git a/lisp/simple.el b/lisp/simple.el index 05a3c4b93d6..2fc1b2dad96 100644 --- a/lisp/simple.el +++ b/lisp/simple.el @@ -5877,6 +5877,67 @@ copy-region-as-kill (setq deactivate-mark t) nil) +(defun copy-next-command-output () + "Prefix command to add the output of the next command to the `kill-ring`. +\"Output\" here refers to text emitted in the echo area, and currently this +is limited to those messages which also appear in the *Messages* buffer." + (interactive) + (let ((md (minibuffer-depth)) + (marker (with-current-buffer "*Messages*" + (point-max-marker)))) + ;; We consider the following states: + ;; - The command (and potentially a few other prefix commands) has just + ;; been run, `post-command-hook' is unaffected yet and `pre-command-hook' + ;; and `prefix-command-*' hooks are set. + ;; - The next command is about to be executed: we already run + ;; `pre-command-hook'. All the hooks are set. + ;; - We just finished running the next command: `post-command-hook' + ;; should then hopefully remove all the hooks. + ;; - Within a minibuffer: commands run in the minibuffer should not affects + ;; hooks since they are either "within" another prefix command + ;; (such as `C-x 8 u') or within the command we want to affect. + ;; We do (re)set the `marker', OTOH so as to try and skip the messages + ;; that occur while we're inside the minibuffer. + (cl-labels ((pre () + (unless (> (minibuffer-depth) md) + (add-hook 'post-command-hook #'post) + (prepare))) + (prepare () + (with-current-buffer "*Messages*" + (move-marker marker (point-max)))) + (preserve () + (unless (> (minibuffer-depth) md) + (remove-hook 'post-command-hook #'post) + (add-hook 'pre-command-hook #'pre))) + (echo () + (unless (> (minibuffer-depth) md) + "[copy-output]")) + (post () + (if (> (minibuffer-depth) md) + ;; Prepare, in case there's no pre-command-hook before + ;; the next post-command-hook. E.g. in the case of + ;; execute-extended-command. + (prepare) + (remove-hook 'pre-command-hook #'pre) + (remove-hook 'post-command-hook #'post) + (remove-hook 'prefix-command-preserve-state-hook + #'preserve) + (remove-hook 'prefix-command-echo-keystrokes-functions + #'echo) + (prefix-command-update) + (with-current-buffer (marker-buffer marker) + (when (< marker (point-max)) + (kill-new (buffer-substring marker (point-max))))) + (set-marker marker nil)))) + (add-hook 'prefix-command-preserve-state-hook #'preserve) + (add-hook 'prefix-command-echo-keystrokes-functions #'echo) + ;; (message "BEFORE: prefix-arg=%S current-prefix-arg=%S" + ;; prefix-arg current-prefix-arg) + (prefix-command-preserve-state) + ;; (message "AFTER: prefix-arg=%S current-prefix-arg=%S" + ;; prefix-arg current-prefix-arg) + ))) + (defun kill-ring-save (beg end &optional region) "Save the region as if killed, but don't kill it. In Transient Mark mode, deactivate the mark.