Re: async-shell-command and prefix argument

[Marcin Borkowski <mbork@mbork.pl>]

On 2019-01-20, at 04:40, Eli Zaretskii <eliz@gnu.org> wrote:

>> From: Juri Linkov <juri@linkov.net>
>> Date: Sat, 19 Jan 2019 23:19:19 +0200
>> Cc: Eli Zaretskii <eliz@gnu.org>, emacs-devel@gnu.org
>>
>> >> Is something wrong with customizing async-shell-command-display-buffer?
>> >> I have it set to nil for quite some time.
>> >
>> > Would it help for this use-case?  That is, make the output buffers
>> > disappear (even in the presence of some output), but not if a prefix
>> > argument is used?
>>
>> Does C-u already mean inserting the output in the current buffer?
>> Maybe then you could use e.g. M-0 prefix arg?
>
> We already have async-shell-command-display-buffer, which can be
> customized to makes the buffer appear only if it has something in it.
> Why is that not enough?  Is the case where the user decides up front
> she doesn't want to see the buffer, ever, no matter what's in it, an
> important enough use case?  And if it is, why a new value of
> async-shell-command-display-buffer couldn't cater even to that weird
> use case?

Well, if `async-shell-command-display-buffer' were extended to allow
that, it would obviously be enough.

I'm astonished, however, that you consider this a `weird use-case'.
I didn't even bother to explain it, since it seems so natural for me.

Basically, I would consider it like functions.  Many commands run
through M-! or M-& are like "pure functions" - you are basically
interested in their output.  Think `ls' or `git status' or `date'.
(These are not great examples, since Emacs has superior replacements for
them, but take `vagrant global-status' for instance.)

OTOH, some external commands are there only for their side effects -
think `rm' or `aunpack or `xdg-open'.  (Notice that the last two often
/have/ output, only that you may be not interested in seeing it.)

Now, M-& can be easily configured to fit one or the other, but not
both.

Does it make sense?

--
Marcin Borkowski
http://mbork.pl