Re: [PATCH] Add facility to collect stderr of async subprocess

[Tino Calancha <tino.calancha@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 1721 bytes --]



On Thu, 6 Oct 2016, Eli Zaretskii wrote:

>> From: Tino Calancha <tino.calancha@gmail.com>
>> Date: Thu, 6 Oct 2016 17:37:05 +0900 (JST)
>> Cc: jwiegley@gmail.com, Emacs developers <emacs-devel@gnu.org>,
>> 	michael.albinus@gmx.de, Tino Calancha <tino.calancha@gmail.com>
>>
>>> Actually, the need in this separation is rather rare.  Which is not
>>> surprising, since running commands from a terminal by default delivers
>>> both stdout and stderr to the screen, and the cases where these are
>>> redirected separately are rare.
>> It depends of what the user is doing.  `shell-command' and
>> `async-shell-command' have being offering that since long time ago.
>>
>> It is quite common redirect stderr from a shell: all shells allow that
>> AFAIK.
>
> My point is not about allowing it -- we definitely do.  My point is
> about the importance of having this in every API.
If Michael is not ging to support it in remote i must agree with you
and say that is not important. 
>I'm saying that
> this feature is relatively rarely needed, that's all.  How many times
> did you need to redirect stderr separately from stdout in shell
> commands you run from the shell prompt?
Honestly, not often.

We might modify the doc strings for shell-comamand and 
async-shell-command, following part:
-----
In Elisp, you will often be better served by calling ‘start-process’
directly, since it offers more control and does not impose the use of a
shell (with its need to quote arguments).
-----

I understand what Stefan means here with more control, but someone may 
argue that s-c and a-s-c allow the possibility to separate stdout from
stderr, which s-p does not.  That sounds like less control, at least
with respect the output.