async-shell-command and prefix argument

async-shell-command and prefix argument

[Marcin Borkowski]

Hi all,

almost three years ago I wrote a blog post about `async-shell-command'.
I wrote that I'm going to ask this on emacs-devel and (unfortunately)
I seemingly forgot about it.  I was reminded about this last week, so
I'm doing it now.

Basically, the post explains most of my problem:
http://mbork.pl/2016-04-12_Showing_some_of_those_Async_Shell_Command_buffers
and an (extremely hackish) solution.  Since the prefix argument to
`async-shell-command' is pretty useless, I would like it to make the
output window disappear (or appear, whichever is the saner default,
possibly decided by some variable).

Does such an idea make sense?  Should I file a feature request?

Best,

--
Marcin Borkowski
http://mbork.pl

Re: async-shell-command and prefix argument

[Eli Zaretskii]

> From: Marcin Borkowski <mbork@mbork.pl>
> Date: Mon, 14 Jan 2019 21:49:47 +0100
> 
> Basically, the post explains most of my problem:
> http://mbork.pl/2016-04-12_Showing_some_of_those_Async_Shell_Command_buffers
> and an (extremely hackish) solution.  Since the prefix argument to
> `async-shell-command' is pretty useless, I would like it to make the
> output window disappear (or appear, whichever is the saner default,
> possibly decided by some variable).
> 
> Does such an idea make sense?  Should I file a feature request?

Is something wrong with customizing async-shell-command-display-buffer?
I have it set to nil for quite some time.

Re: async-shell-command and prefix argument

[Marcin Borkowski]

On 2019-01-15, at 18:32, Eli Zaretskii <eliz@gnu.org> wrote:

>> From: Marcin Borkowski <mbork@mbork.pl>
>> Date: Mon, 14 Jan 2019 21:49:47 +0100
>>
>> Basically, the post explains most of my problem:
>> http://mbork.pl/2016-04-12_Showing_some_of_those_Async_Shell_Command_buffers
>> and an (extremely hackish) solution.  Since the prefix argument to
>> `async-shell-command' is pretty useless, I would like it to make the
>> output window disappear (or appear, whichever is the saner default,
>> possibly decided by some variable).
>>
>> Does such an idea make sense?  Should I file a feature request?
>
> 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?

Best,

--
Marcin Borkowski
http://mbork.pl

Re: async-shell-command and prefix argument

[Juri Linkov]

>>> Basically, the post explains most of my problem:
>>> http://mbork.pl/2016-04-12_Showing_some_of_those_Async_Shell_Command_buffers
>>> and an (extremely hackish) solution.  Since the prefix argument to
>>> `async-shell-command' is pretty useless, I would like it to make the
>>> output window disappear (or appear, whichever is the saner default,
>>> possibly decided by some variable).
>>>
>>> Does such an idea make sense?  Should I file a feature request?
>>
>> 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?

Re: async-shell-command and prefix argument

[Eli Zaretskii]

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

Re: async-shell-command and prefix argument

[Marcin Borkowski]

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

Re: async-shell-command and prefix argument

[Eli Zaretskii]

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

> Does it make sense?

Not really, sorry.

Re: async-shell-command and prefix argument

[Marcin Borkowski]

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

Re: async-shell-command and prefix argument

[Eli Zaretskii]

> From: Marcin Borkowski <mbork@mbork.pl>
> Cc: juri@linkov.net, emacs-devel@gnu.org
> 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.

Re: async-shell-command and prefix argument

[Marcin Borkowski]

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

>> From: Marcin Borkowski <mbork@mbork.pl>
>> Cc: juri@linkov.net, emacs-devel@gnu.org
>> 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.

Agreed, I fixed that on my machine.

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

In such a case I would probably miss that piece of information anyway.

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

Well, let us agree to disagree here (at least partially).  I sometimes
do ignore diagnostics, and I sometimes have good reasons.  (Like
underfull boxes in LaTeX, recently some warnings due to a buggy JS
library used in a project I'm working on, etc.)  Sometimes fixing is
indeed a better idea (like with the gtk problem above).

I think the main problem here is that windows popping up here and there
annoy me *a lot*, especially if the information they give is useless in
99.99% cases (and possibly 100%).  Also, if some system works even only
99% of the time, humans usually quickly train themselves to ignore any
diagnostics.

And thanks for calling me a "veteran Emacs user".  I'm not sure
I deserve such a label - I've been only using Emacs for a bit less than
20 years;-).

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

I will shock you, but yes.  I routinely ignore any compilation warnings
when I compile a new Emacs from source;-).  For other problems, it may
depend on the kind of problem.  I often mistype some command, and
sometimes I do bother to press C-h l to see what I did and sometimes
not.  (A lot depends on what mode I was in when the mistyping occured -
in some modes it might be catastrophic.)  Sometimes when something stops
working I simply restart Emacs (this happens especially with things like
timers) - my feeling is that it might be some extremely obscure bug or
(more problably) me doing something stupid (like killing some buffer
some code depends on).  Probably not worth investigating due to time
constraints.

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

Precisely.  It is the old way, isn't it?  If the user wants to shoot
themselves in the foot, why not let them?  This is how Unix works, this
is how C works, this is how (La)TeX works, this is how Lisp works.
I see no reason to move to the shackles of Javaland (been there once,
for an excursion - a simple Android app - and I'm not going there
again).

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

Well, C-u is taken, but what it does is useless.

Anyway, I think we should close this discussion.  Neither of us will
convince the other one (probably), I'm not sure more will be said, so
I learned what I learned from you in this thread and I don't expect
more (but thanks for that!), and I modified my Emacs to do what I want
anyway (though in a very hackish way).

Best,

--
Marcin Borkowski
http://mbork.pl