bug#18133: Suppressing asynchronous command output

[Reuben Thomas <rrt@sc3d.org>]

[-- Attachment #1: Type: text/plain, Size: 2322 bytes --]

On 29 December 2016 at 23:08, Juri Linkov <juri@linkov.net> wrote:

> > 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*".
>
> Maybe you could construct a lambda in ‘shell-command’
> containing the buffer name dynamically bound to the value of
> (or output-buffer "*Async Shell Command*"), then set this lambda
> to the process-filter, as we already do in ‘shell-command’ with
>
> (set-process-filter proc 'comint-output-filter)
>
> i.e. something like
>
> (set-process-filter proc `(lambda (process string)
>                            (when ...
>                             (display-buffer ,(or output-buffer "*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.
>
> If the above solution will work, then we'll need a new customizable
> variable
> like ‘async-shell-command-display-buffer’.  And also ‘display-buffer’ in
> ‘shell-command’ will need to be adjusted in the way recommended by Martin.
>

​I tried to integrate these changes with Eli's feedback, but I got stuck.

"The way recommended by Martin" involves a new minor mode,
async-shell-lazy-pop-up-mode, which I tried to avoid; Eli didn't seem to
support its addition, either.

I'm not sure what the variable async-shell-command-display-buffer is
supposed to contain. (It does not seem to be the name of the buffer to be
matched.)

I am unclear what goes in the ellipsis after "when" in the sample code
above; it seems to imply a test for whether the buffer should be displayed,
but I already handled that in my patch with the preoutput-filter function.

So, the above seems to be an alternative suggestion to Eli's, rather than a
complementary one, as I first thought.

It would be good if you experts could agree on an approach that I could
quickly implement. I'm out of my depth here as far as design goes, and
while I'm learning a bit, I'm not sure it's a good use of the total amount
of time we seem to be expending between us!

-- 
http://rrt.sc3d.org

[-- Attachment #2: Type: text/html, Size: 3688 bytes --]