bug-gnu-emacs
[Top][All Lists]
Advanced

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





reply via email to

[Prev in Thread] Current Thread [Next in Thread]