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: Jeremy Bryant <jb <at> jeremybryant.net>
Cc: 65511 <at> debbugs.gnu.org, monnier <at> iro.umontreal.ca
Subject: bug#65511: [PATCH] copy-next-command-output suggestion
Date: Fri, 25 Aug 2023 09:05:42 +0300

> From: Jeremy Bryant <jb <at> jeremybryant.net>
> Date: Thu, 24 Aug 2023 22:46:28 +0100
> 
> The command copy-next-command-output copies the output of the next
> command, and having used it for several months, I would like to suggest
> this for Emacs core.  It doesn't appear to be part of Emacs.  I
> typically bind this C-c u.
> 
> This code was provided by Stefan on this list or emacs-devel, so the
> author should be changed accordingly (I haven't modified Stefan's code,
> just used it).
> 
> Thoughts welcome as this is my first patch suggestion.  It could also be
> put in a package in ELPA.  I have signed the paperwork.

Thanks.  On the formal level, this needs a NEWS entry and a suitable
change for the user manual.  Also, please always accompany changes by
a commit log message formatted according to our conventions (see
CONTRIBUTE and the examples shown by "git log").

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.

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?

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? if not, how does this
command prevent that?

And finally, this feature only works with commands whose output goes
to *Messages*, right?  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.

Previous Next

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