From: Eli Zaretskii <eliz@gnu.org>
To: Stefan Monnier <monnier@iro.umontreal.ca>
Cc: jb@jeremybryant.net, 65511@debbugs.gnu.org
Subject: bug#65511: [PATCH] copy-next-command-output suggestion
Date: Tue, 05 Sep 2023 14:14:48 +0300 [thread overview]
Message-ID: <83jzt450t3.fsf@gnu.org> (raw)
In-Reply-To: <jwvjzt5mxg5.fsf-monnier+emacs@gnu.org> (message from Stefan Monnier on Mon, 04 Sep 2023 18:17:44 -0400)
> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Cc: Jeremy Bryant <jb@jeremybryant.net>, 65511@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.
> \f
> * 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"
next prev parent reply other threads:[~2023-09-05 11:14 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-08-24 21:46 bug#65511: [PATCH] copy-next-command-output suggestion Jeremy Bryant
2023-08-25 6:05 ` Eli Zaretskii
2023-09-04 22:17 ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-09-05 11:14 ` Eli Zaretskii [this message]
2023-09-05 13:10 ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-09-05 18:33 ` Jeremy Bryant
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.gnu.org/software/emacs/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=83jzt450t3.fsf@gnu.org \
--to=eliz@gnu.org \
--cc=65511@debbugs.gnu.org \
--cc=jb@jeremybryant.net \
--cc=monnier@iro.umontreal.ca \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).