From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED.blaine.gmane.org!not-for-mail From: Marcin Borkowski Newsgroups: gmane.emacs.devel Subject: Re: async-shell-command and prefix argument Date: Thu, 24 Jan 2019 18:32:47 +0100 Message-ID: <8736pi7ygw.fsf@mbork.pl> References: <87bm4jnevo.fsf@mbork.pl> <83zhs1ddxw.fsf@gnu.org> <871s5dt3cj.fsf@mbork.pl> <87won0fia8.fsf@mail.linkov.net> <83a7jwatez.fsf@gnu.org> <87lg3foqwh.fsf@mbork.pl> <835zujbanu.fsf@gnu.org> <878szfnkhq.fsf@mbork.pl> <83r2d69fc2.fsf@gnu.org> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226"; logging-data="7782"; mail-complaints-to="usenet@blaine.gmane.org" User-Agent: mu4e 1.1.0; emacs 27.0.50 Cc: emacs-devel@gnu.org, juri@linkov.net To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Thu Jan 24 18:35:52 2019 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([209.51.188.17]) by blaine.gmane.org with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1gmius-0001t5-W5 for ged-emacs-devel@m.gmane.org; Thu, 24 Jan 2019 18:35:51 +0100 Original-Received: from localhost ([127.0.0.1]:57531 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1gmiur-0001Kg-LE for ged-emacs-devel@m.gmane.org; Thu, 24 Jan 2019 12:35:49 -0500 Original-Received: from eggs.gnu.org ([209.51.188.92]:37597) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1gmisv-0000fb-4q for emacs-devel@gnu.org; Thu, 24 Jan 2019 12:33:50 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1gmiss-0006sf-W9 for emacs-devel@gnu.org; Thu, 24 Jan 2019 12:33:48 -0500 Original-Received: from mail.mojserwer.eu ([195.110.48.8]:51948) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1gmisl-0006f2-DY; Thu, 24 Jan 2019 12:33:41 -0500 Original-Received: from localhost (localhost [127.0.0.1]) by mail.mojserwer.eu (Postfix) with ESMTP id 089C5E6BE2; Thu, 24 Jan 2019 18:33:35 +0100 (CET) X-Virus-Scanned: Debian amavisd-new at mail.mojserwer.eu Original-Received: from mail.mojserwer.eu ([127.0.0.1]) by localhost (mail.mojserwer.eu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CtCsGdofPJ9n; Thu, 24 Jan 2019 18:33:27 +0100 (CET) Original-Received: from localhost (static-dwadziewiec-jedenpiec7.echostar.pl [109.232.29.157]) by mail.mojserwer.eu (Postfix) with ESMTPSA id 86FC3E6650; Thu, 24 Jan 2019 18:33:26 +0100 (CET) In-reply-to: <83r2d69fc2.fsf@gnu.org> X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 195.110.48.8 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.org gmane.emacs.devel:232674 Archived-At: On 2019-01-21, at 16:54, Eli Zaretskii wrote: >> From: Marcin Borkowski >> 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