Re: async-shell-command and prefix argument

[Marcin Borkowski <mbork@mbork.pl>]

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

>> From: Marcin Borkowski <mbork@mbork.pl>
>> Cc: Juri Linkov <juri@linkov.net>, emacs-devel@gnu.org
>> Date: Sun, 20 Jan 2019 06:10:38 +0100
>>
>> I'm astonished, however, that you consider this a `weird use-case'.
>
> It is weird because you, in effect, give up any diagnostic output from
> the command, such as warnings or errors, up front.  Since no one can
> reliably predict such diagnostics, I wonder how do you even know that
> those commands did what you intended them to do.  It's like flying
> blind while also turning off all the instruments.
>
>> 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.)
>
> Commands invoked "for side effects" will not produce any output, so
> setting async-shell-command-display-buffer to nil will do exactly what
> (I think) you want: display nothing if there's no output, and display
> the diagnostics otherwise.
>
> OTOH, if such a command does display something, it means the author of
> the command thought it was important enough to show that, even though
> the command is "for side effects".

Well, you are right - in theory.  Practice is different.

Here are some examples.

1. Opening a png file in Gimp with xdg-open

--8<---------------cut here---------------start------------->8---
$ xdg-open redacted.png

(gimp-2.10:29264): Gtk-WARNING **: 21:13:40.274: Unable to locate theme engine in module_path: "adwaita",

(gimp-2.10:29264): Gtk-WARNING **: 21:13:40.277: Unable to locate theme engine in module_path: "adwaita",

(file-png:29282): Gtk-WARNING **: 21:13:42.558: Unable to locate theme engine in module_path: "adwaita",

(file-png:29282): Gtk-WARNING **: 21:13:42.562: Unable to locate theme engine in module_path: "adwaita",
--8<---------------cut here---------------end--------------->8---

I know it worked because I can see a Gimp window/frame open.

2. Running (pdf)latex on a known and tested file (so no need for
diagnostics), only to produce the pdf.

I know it worked because I can see (and view) the pdf.  (Besides, I know
the file compiles correctly anyway, I just happened to delete the pdf
and I want to recreate it.)

3. Unpacking an archive with (more or less) known contents.

--8<---------------cut here---------------start------------->8---
$ aunpack zzz.zip
Archive:  zzz.zip
 extracting: Unpack-6002/aaa
 extracting: Unpack-6002/bbb
 extracting: Unpack-6002/ccc
zzz.zip: extracted to `zzz' (multiple files in root)
--8<---------------cut here---------------end--------------->8---

I know it worked because I press `g' in Dired and I can see the results
of the unpacking.

4. Viewing a pdf without the synctex file in evince.

--8<---------------cut here---------------start------------->8---
$ evince mgr.pdf
! SyncTeX Error : No file?
--8<---------------cut here---------------end--------------->8---

>> Does it make sense?
>
> Not really, sorry.

Is it better now?

It is all about flexibility.  The author may have thought that the
output is important.  As a user, knowing my situation, I know that it is
not important /for me/.  (And I take the risk of a possible but unlikely
situation of something going wrong and me not noticing, like having
a full disk.)  I could say ">/dev/null 2>&1" to achieve what I want.
It's just that C-u is much more convenient.

Best,

--
Marcin Borkowski
http://mbork.pl