Re: async-shell-command and prefix argument

[Marcin Borkowski <mbork@mbork.pl>]

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