GNU bug report logs - #65511
[PATCH] copy-next-command-output suggestion

Previous Next

Full log

View this message in rfc822 format

From: Eli Zaretskii <eliz <at> gnu.org>
To: Stefan Monnier <monnier <at> iro.umontreal.ca>
Cc: jb <at> jeremybryant.net, 65511 <at> debbugs.gnu.org
Subject: bug#65511: [PATCH] copy-next-command-output suggestion
Date: Tue, 05 Sep 2023 14:14:48 +0300

> From: Stefan Monnier <monnier <at> iro.umontreal.ca>
> Cc: Jeremy Bryant <jb <at> jeremybryant.net>,  65511 <at> debbugs.gnu.org
> Date: Mon, 04 Sep 2023 18:17:44 -0400
> 
> > 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.

Sorry, I meant to say that this stuff should NOT be put into the
clipboard.  Which is why I suggested to bind interprogram-cut-function
to nil.

> > 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.

Maybe just document it?

> 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`.

Maybe we should indeed try to come up with such an alternative
implementation.

> +@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.

That "them" is ambiguous.  Better say "those messages" or somesuch.

> --- 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
                                                                          ^
Period missing there.

> +    ;; - Within a minibuffer: commands run in the minibuffer should not affects
                                                                           ^^^^^^^

"affect"

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.