Re: async-shell-command and prefix argument

[Eli Zaretskii]

> From: Marcin Borkowski <address@hidden>
> Cc: address@hidden, address@hidden
> Date: Sun, 20 Jan 2019 21:26:41 +0100
> 
> > 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",

Can be easily fixed, see below.

> 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.

I very much doubt that you could easily spot problems just by looking
at the list of files which wound up in Dired.  E.g., what if some file
failed to extract, due to a bug in aunpack, and the list of extracted
files is very long?

> 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?

This exchange is in response to your surprise that I consider this use
case weird.  The examples you gave don't really change anything.  They
show that you are willing to give up on seeing diagnostic messages
because you think you know in advance what they will tell you in each
and every case.  That is a strange assumption; IME it is invalidated
by your potential, if rare, typing mistakes; system updates that
replace programs and libraries with new versions that have exciting
new bugs; and by other similarly unexpected calamities.  It is strange
to hear from a veteran Emacs user that he chooses to ignore
diagnostics, rather than pay attention to them and attempt to solve
the underlying reasons.  For example, according to
https://askubuntu.com/questions/774664/gtk-warning-unable-to-locate-theme-engine-in-module-path-adwaita-error-o,
you can fix the first of the above problems by installing one,
possibly two, packages.

I hope you don't ignore Emacs problems in the same way.

> 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.

Or make a shell script that redirects stdout/stderr, and use that
thereafter.

> It's just that C-u is much more convenient.

C-u is already taken.  At best, you will have to do something like
"C-u 0" or "M-0" instead.  I doubt that's really better than
redirecting to /dev/null, and once again, I'm surprised that someone
would want to discard that output in the first place.