[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#18133: Suppressing asynchronous command output
From: |
Eli Zaretskii |
Subject: |
bug#18133: Suppressing asynchronous command output |
Date: |
Thu, 29 Dec 2016 17:50:06 +0200 |
> From: Reuben Thomas <rrt@sc3d.org>
> Date: Wed, 28 Dec 2016 20:58:40 +0000
> Cc: Juri Linkov <juri@linkov.net>, martin rudalics <rudalics@gmx.at>,
> 18133@debbugs.gnu.org
>
> It appears:
>
> . in ibuf-ext.el, as one of several strings users can select
> . in tramp-adb.el as a buffer where the shell output should go
> . in tramp.el, likewise
> . in simple.el, likewise
> . in comments in some other files
>
> By contrast, you were hard-coding it in a function that should provide
> optional behavior for buffers that are not necessarily related to
> shell output. In that context, I think the user should be able to
> instruct Emacs about the buffers which should exhibit this behavior.
>
> As I said, the name is editable in M-x customize-variable.
Yes, but AFAIU, that doesn't affect the function about which I was
commenting.
> > You can tick/untick the option for "*Async Shell Command*", and, when it
> is ticked, the regexp can be
> edited.
>
> But if I select that, what I get is that the buffer will not be
> displayed at all, right? What will trigger its display when it
> becomes non-empty? Sorry if I'm missing something obvious.
>
> The buffer will be displayed by comint-make-newly-written-buffer-visible,
> which I've added to the default value
> of comint-preoutput-filter-functions. At present the buffer name is hard
> coded there, so this will only work for
> "*Async Shell Command*".
>
> So, to allow the user to be able to change the name, I suppose another user
> option would need to be
> introduced.
>
> However, that is beyond the scope of this bug, which is simply to change the
> behaviour for asynchronous
> uses of shell-command.
The name comint-make-newly-written-buffer-visible doesn't imply that
it only handles that single buffer. We could, of course, change the
name so that it did, but IMO making the function customizable wrt
buffers it handles would be a much better way.
- bug#18133: Suppressing asynchronous command output, (continued)
- bug#18133: Suppressing asynchronous command output, martin rudalics, 2016/12/27
- bug#18133: Suppressing asynchronous command output, Juri Linkov, 2016/12/26
- bug#18133: Suppressing asynchronous command output, Reuben Thomas, 2016/12/26
- bug#18133: Suppressing asynchronous command output, Reuben Thomas, 2016/12/26
- bug#18133: Suppressing asynchronous command output, Eli Zaretskii, 2016/12/27
- bug#18133: Suppressing asynchronous command output, Reuben Thomas, 2016/12/27
- bug#18133: Suppressing asynchronous command output, Eli Zaretskii, 2016/12/27
- bug#18133: Suppressing asynchronous command output, Reuben Thomas, 2016/12/27
- bug#18133: Suppressing asynchronous command output, Eli Zaretskii, 2016/12/28
- bug#18133: Suppressing asynchronous command output, Reuben Thomas, 2016/12/28
- bug#18133: Suppressing asynchronous command output,
Eli Zaretskii <=
- bug#18133: Suppressing asynchronous command output, Juri Linkov, 2016/12/29
- bug#18133: Suppressing asynchronous command output, Reuben Thomas, 2016/12/30
- bug#18133: Suppressing asynchronous command output, Eli Zaretskii, 2016/12/30
- bug#18133: Suppressing asynchronous command output, Reuben Thomas, 2016/12/30
- bug#18133: Suppressing asynchronous command output, Juri Linkov, 2016/12/30
- bug#18133: Suppressing asynchronous command output, Reuben Thomas, 2016/12/30
- bug#18133: Suppressing asynchronous command output, Eli Zaretskii, 2016/12/31