[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#18133: Suppressing asynchronous command output

From: Reuben Thomas
Subject: bug#18133: Suppressing asynchronous command output
Date: Fri, 30 Dec 2016 18:28:46 +0000

On 29 December 2016 at 23:08, Juri Linkov <address@hidden> 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!


reply via email to

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