async-shell-command

async-shell-command

[Marcin Borkowski]

Hi Emacs devs,

I have a minor issue with the `async-shell-command'.  I'd like it not to
display the *Async Shell Command* buffer (and I modified
`display-buffer-alist' accordingly), but then again /sometimes/ I want
to see that buffer.  It is only natural to use the prefix argument for
that, so here's what I did:

--8<---------------cut here---------------start------------->8---
(defun async-shell-dispatch (orig-fun command &optional output-buffer error-buffer)
  "If OUTPUT-BUFFER is '(4) (i.e., C-u), temporarily turn off
blocking of displaying the output-buffer."
  (if (equal output-buffer '(4))
      (let ((display-buffer-alist
	     (remove '("^*Async Shell Command*" . (display-buffer-no-window)) display-buffer-alist)))
	(funcall orig-fun command nil error-buffer))
    (funcall orig-fun command output-buffer error-buffer)))

(advice-add 'async-shell-command :around 'async-shell-dispatch)
--8<---------------cut here---------------end--------------->8---

(BTW, I described all that on my blog:
http://mbork.pl/2016-04-07_Hiding_those_annoying_Async_Shell_Command_buffers
http://mbork.pl/2016-04-12_Showing_some_of_those_Async_Shell_Command_buffers)

Of course, this is extremely hackish.  I thought that stock Emacs could
use the prefix argument to `async-shell-command' for something else than
"make this synchronous after all, and put the result at point", which
seems odd (and not documented, btw).  For instance, C-u M-& might /not/
show the *Async Shell Command* buffer, and when some option is set, this
hiding/showing behavior would be reversed (as in my solution).  OTOH,
maybe the current way of doing things is fine, and just needs mentioning
in the docstring?

Any ideas?  WDYT?

-- 
Marcin Borkowski
http://octd.wmi.amu.edu.pl/en/Marcin_Borkowski
Faculty of Mathematics and Computer Science
Adam Mickiewicz University

Re: async-shell-command

[John Wiegley]

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

>>>>> Marcin Borkowski <mbork@mbork.pl> writes:

> Of course, this is extremely hackish. I thought that stock Emacs could use
> the prefix argument to `async-shell-command' for something else than "make
> this synchronous after all, and put the result at point", which seems odd
> (and not documented, btw). For instance, C-u M-& might /not/ show the *Async
> Shell Command* buffer, and when some option is set, this hiding/showing
> behavior would be reversed (as in my solution). OTOH, maybe the current way
> of doing things is fine, and just needs mentioning in the docstring?

> Any ideas?  WDYT?

None of the current invocation commands use a prefix argument to control
display, so this would be a departure from established practice. I think the
change you've described is better done locally, for those who want such
behavior.

Another way of doing this that might be nicer would be to check if the
shell-command string ends in "&!" instead of "&", and to take that as an
indication it should be executed both asynchronously and "silently" (without
display).

-- 
John Wiegley                  GPG fingerprint = 4710 CF98 AF9B 327B B80F
http://newartisans.com                          60E1 46C4 BD1A 7AC1 4BA2

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 629 bytes --]

Re: async-shell-command

[Marcin Borkowski]

On 2016-04-16, at 20:44, John Wiegley <jwiegley@gmail.com> wrote:

>>>>>> Marcin Borkowski <mbork@mbork.pl> writes:
>
>> Of course, this is extremely hackish. I thought that stock Emacs could use
>> the prefix argument to `async-shell-command' for something else than "make
>> this synchronous after all, and put the result at point", which seems odd
>> (and not documented, btw). For instance, C-u M-& might /not/ show the *Async
>> Shell Command* buffer, and when some option is set, this hiding/showing
>> behavior would be reversed (as in my solution). OTOH, maybe the current way
>> of doing things is fine, and just needs mentioning in the docstring?
>
>> Any ideas?  WDYT?
>
> None of the current invocation commands use a prefix argument to control
> display, so this would be a departure from established practice. I think the
> change you've described is better done locally, for those who want such
> behavior.

I expected such an answer, and I pretty much agree.  I just wanted to
ask whether I'm the only one who could find something like that useful
(from some private email exchange I know that not), and whether the UI
I proposed (C-u) makes sense (this is at least debatable).

> Another way of doing this that might be nicer would be to check if the
> shell-command string ends in "&!" instead of "&", and to take that as an
> indication it should be executed both asynchronously and "silently" (without
> display).

That sounds interesting.  What if the command ends with "!" alone?
Should it be synchronous and silent?  (I guess not.)

John, would you like me to explore this idea further and try to come up
with a patch?  Are there any other ideas for the UI?

Also, no matter how we indicate "silent" runs, what do people think
about the idea of an option to /invert/ things, so that running
a command /without/ the "silent" flag makes it silent (IOW, making
`async-shell-command' "silent" by default)?

Also, I'm pretty sure that the current meaning of the prefix argument
for `async-shell-command' /must/ be documented - it is far from obvious,
and can be learned only from careful reading of the code.  I'm going to
prepare such a patch for docs (both the docstring and the manual) first.

Best,

-- 
Marcin Borkowski
http://octd.wmi.amu.edu.pl/en/Marcin_Borkowski
Faculty of Mathematics and Computer Science
Adam Mickiewicz University

RE: async-shell-command

[Drew Adams]

> Also, I'm pretty sure that the current meaning of the prefix argument
> for `async-shell-command' /must/ be documented - it is far from obvious,
> and can be learned only from careful reading of the code.

You need not read the code, but you do need to read the doc
string carefully.  The info about the arguments is available,
but not clearly and directly.

For `async-shell-command' the doc string says:

 "Like `shell-command', but..."

But like it in what ways, one might wonder?  In fact and in
particular, it is like `shell-command' wrt the arguments.

It would be better for this doc string to explicitly refer a
reader to the doc string of `shell-command' for info about
the arguments, including the use of a prefix arg.

> I'm going to prepare such a patch for docs (both the docstring
> and the manual) first.

Thank you.  I'm sure it will be an improvement.

(Note too that the second line of the doc string should not be
blank.  Dunno why some people seem to think it is right to add
such a line.  I suspect that it comes from reading the doc
string only in the Lisp source instead of trying `C-h f'.)

Re: async-shell-command

[John Wiegley]

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

>>>>> Marcin Borkowski <mbork@mbork.pl> writes:

> That sounds interesting. What if the command ends with "!" alone? Should it
> be synchronous and silent? (I guess not.)

That doesn't seem to make a lot of sense, does it...

> John, would you like me to explore this idea further and try to come up with
> a patch? Are there any other ideas for the UI?

I'm not sure about changing these functions in core Emacs. I can think of
still other behaviors (like not showing the async output buffer until there is
output to display). Rather than changing these venerable commands, it might be
better to explore the UI possibilities in an add-on (using advice, maybe?) for
the time being.

Or maybe the concept the "execute but hide the buffer" should just be a new
command, provided by an ELPA package that offers more options related to
executing shell commands from the minibuffer?

> Also, I'm pretty sure that the current meaning of the prefix argument for
> `async-shell-command' /must/ be documented - it is far from obvious, and can
> be learned only from careful reading of the code. I'm going to prepare such
> a patch for docs (both the docstring and the manual) first.

Yes, it should definitely be documented.

-- 
John Wiegley                  GPG fingerprint = 4710 CF98 AF9B 327B B80F
http://newartisans.com                          60E1 46C4 BD1A 7AC1 4BA2

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 629 bytes --]

Re: async-shell-command

[Marcin Borkowski]

On 2016-04-19, at 00:47, John Wiegley <jwiegley@gmail.com> wrote:

>>>>>> Marcin Borkowski <mbork@mbork.pl> writes:
>
>> That sounds interesting. What if the command ends with "!" alone? Should it
>> be synchronous and silent? (I guess not.)
>
> That doesn't seem to make a lot of sense, does it...

Well, it would follow the Unix tradition: do what should be done, say
nothing;-).

But joking aside, I agree.

>> John, would you like me to explore this idea further and try to come up with
>> a patch? Are there any other ideas for the UI?
>
> I'm not sure about changing these functions in core Emacs. I can think of
> still other behaviors (like not showing the async output buffer until there is
> output to display). Rather than changing these venerable commands, it might be
> better to explore the UI possibilities in an add-on (using advice, maybe?) for
> the time being.
>
> Or maybe the concept the "execute but hide the buffer" should just be a new
> command, provided by an ELPA package that offers more options related to
> executing shell commands from the minibuffer?

OK.  I'm not sure whether I agree (probably not), but I solved the
problem in my init.el anyway;-).  I'll think about both options (I would
prefer the first one, configurable with an option).

>> Also, I'm pretty sure that the current meaning of the prefix argument for
>> `async-shell-command' /must/ be documented - it is far from obvious, and can
>> be learned only from careful reading of the code. I'm going to prepare such
>> a patch for docs (both the docstring and the manual) first.
>
> Yes, it should definitely be documented.

So I'll start with reaping this low-hanging fruit;-).

Best,

-- 
Marcin Borkowski
http://octd.wmi.amu.edu.pl/en/Marcin_Borkowski
Faculty of Mathematics and Computer Science
Adam Mickiewicz University