* Re: master 3b4e312: Improve documentation around standard error pipes (Bug#35328).
[not found] ` <20190422140756.5C1042088F@vcs0.savannah.gnu.org>
@ 2019-04-22 20:59 ` Michael Albinus
2019-04-23 5:45 ` Eli Zaretskii
0 siblings, 1 reply; 7+ messages in thread
From: Michael Albinus @ 2019-04-22 20:59 UTC (permalink / raw)
To: emacs-devel; +Cc: Philipp Stephani
p.stephani2@gmail.com (Philipp Stephani) writes:
Hi,
[sorry that I chime in such late; I didn't follow the discussion in Bug#35328]
> +@cindex standard error process
> +If @var{stderr} is a buffer, Emacs will create a pipe process, the
> +@dfn{standard error process}. This process will have the default
> +filter (@pxref{Filter Functions}), sentinel (@pxref{Sentinels}), and
> +coding systems (@pxref{Default Coding Systems}). On the other hand,
> +it will use @var{query-flag} as its query-on-exit flag (@pxref{Query
> +Before Exit}). It will be associated with the @var{stderr} buffer
> +(@pxref{Process Buffers}) and send its output (which is the standard
> +error of the main process) there.
FTR, the implementation in Tramp is different from what is described
here. And honestly, I even don't know, how to implement these two
processes for the remote case.
The current implementation in Tramp redirects stderr to a temporary
file, if it is separate from stdout. This temprary file is associated
with the :stderr buffer, and it runs auto-revert-mode. Maybe not very
elegant, but working so far.
I don't know whether we shall document this different behavior, or
whether we shall find an implementation in Tramp for what is
described. For the latter, I would need help, as said. Or at least ideas.
Best regards, Michael.
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: master 3b4e312: Improve documentation around standard error pipes (Bug#35328).
2019-04-22 20:59 ` master 3b4e312: Improve documentation around standard error pipes (Bug#35328) Michael Albinus
@ 2019-04-23 5:45 ` Eli Zaretskii
2019-04-23 7:11 ` Michael Albinus
0 siblings, 1 reply; 7+ messages in thread
From: Eli Zaretskii @ 2019-04-23 5:45 UTC (permalink / raw)
To: Michael Albinus; +Cc: phst, emacs-devel
> From: Michael Albinus <michael.albinus@gmx.de>
> Date: Mon, 22 Apr 2019 22:59:01 +0200
> Cc: Philipp Stephani <phst@google.com>
>
> > +@cindex standard error process
> > +If @var{stderr} is a buffer, Emacs will create a pipe process, the
> > +@dfn{standard error process}. This process will have the default
> > +filter (@pxref{Filter Functions}), sentinel (@pxref{Sentinels}), and
> > +coding systems (@pxref{Default Coding Systems}). On the other hand,
> > +it will use @var{query-flag} as its query-on-exit flag (@pxref{Query
> > +Before Exit}). It will be associated with the @var{stderr} buffer
> > +(@pxref{Process Buffers}) and send its output (which is the standard
> > +error of the main process) there.
>
> FTR, the implementation in Tramp is different from what is described
> here. And honestly, I even don't know, how to implement these two
> processes for the remote case.
>
> The current implementation in Tramp redirects stderr to a temporary
> file, if it is separate from stdout. This temprary file is associated
> with the :stderr buffer, and it runs auto-revert-mode. Maybe not very
> elegant, but working so far.
>
> I don't know whether we shall document this different behavior, or
> whether we shall find an implementation in Tramp for what is
> described. For the latter, I would need help, as said. Or at least ideas.
I think we should at least qualify the above description with its
being accurate for local processes only.
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: master 3b4e312: Improve documentation around standard error pipes (Bug#35328).
2019-04-23 5:45 ` Eli Zaretskii
@ 2019-04-23 7:11 ` Michael Albinus
2019-04-23 10:28 ` Eli Zaretskii
0 siblings, 1 reply; 7+ messages in thread
From: Michael Albinus @ 2019-04-23 7:11 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: phst, emacs-devel
[-- Attachment #1: Type: text/plain, Size: 384 bytes --]
Eli Zaretskii <eliz@gnu.org> writes:
Hi Eli,
>> I don't know whether we shall document this different behavior, or
>> whether we shall find an implementation in Tramp for what is
>> described. For the latter, I would need help, as said. Or at least ideas.
>
> I think we should at least qualify the above description with its
> being accurate for local processes only.
Like this?
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: Type: text/x-patch, Size: 1399 bytes --]
*** /tmp/ediffEO055I 2019-04-23 09:08:54.501926412 +0200
--- /home/albinus/src/emacs/doc/lispref/processes.texi 2019-04-23 09:05:04.977767519 +0200
***************
*** 734,740 ****
Depending on the implementation of the file name handler, it might not
be possible to apply @var{filter} or @var{sentinel} to the resulting
! process object. @xref{Filter Functions}, and @ref{Sentinels}.
Some file name handlers may not support @code{make-process}. In such
cases, this function does nothing and returns @code{nil}.
--- 734,743 ----
Depending on the implementation of the file name handler, it might not
be possible to apply @var{filter} or @var{sentinel} to the resulting
! process object. The @code{:stderr} argument cannot be a pipe; if it
! is a buffer a different implementation will be used to show the buffer
! contents. @xref{Filter Functions}, @ref{Sentinels}, and
! @ref{Accepting Output}.
Some file name handlers may not support @code{make-process}. In such
cases, this function does nothing and returns @code{nil}.
***************
*** 1908,1913 ****
--- 1911,1919 ----
(while (accept-process-output stderr-process))
@end example
+ Reading pending standard error from a process running on a remote host
+ is not possible this way.
+
@node Processes and Threads
@subsection Processes and Threads
@cindex processes, threads
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: master 3b4e312: Improve documentation around standard error pipes (Bug#35328).
2019-04-23 7:11 ` Michael Albinus
@ 2019-04-23 10:28 ` Eli Zaretskii
2019-04-23 12:05 ` Michael Albinus
0 siblings, 1 reply; 7+ messages in thread
From: Eli Zaretskii @ 2019-04-23 10:28 UTC (permalink / raw)
To: Michael Albinus; +Cc: phst, emacs-devel
> From: Michael Albinus <michael.albinus@gmx.de>
> Cc: emacs-devel@gnu.org, phst@google.com
> Date: Tue, 23 Apr 2019 09:11:23 +0200
>
> Like this?
Maybe. But what do you mean by "different implementation" here:
> ! process object. The @code{:stderr} argument cannot be a pipe; if it
> ! is a buffer a different implementation will be used to show the buffer
> ! contents. ^^^^^^^^^^^^^^^^^^^^^^^^
This sounds vague and begs questions. Can we be more clear?
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: master 3b4e312: Improve documentation around standard error pipes (Bug#35328).
2019-04-23 10:28 ` Eli Zaretskii
@ 2019-04-23 12:05 ` Michael Albinus
2019-04-23 12:16 ` Eli Zaretskii
0 siblings, 1 reply; 7+ messages in thread
From: Michael Albinus @ 2019-04-23 12:05 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: phst, emacs-devel
Eli Zaretskii <eliz@gnu.org> writes:
> Maybe. But what do you mean by "different implementation" here:
>
>> ! process object. The @code{:stderr} argument cannot be a pipe; if it
>> ! is a buffer a different implementation will be used to show the buffer
>> ! contents. ^^^^^^^^^^^^^^^^^^^^^^^^
>
> This sounds vague and begs questions. Can we be more clear?
I don't believe implementation details belong into that manual. What about
The @code{:stderr} argument cannot be a pipe process, file name handlers
do not support pipe processes for this. A buffer as @code{:stderr}
argument is accepted, its contents is shown without the use of pipe processes.
Best regards, Michael.
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: master 3b4e312: Improve documentation around standard error pipes (Bug#35328).
2019-04-23 12:05 ` Michael Albinus
@ 2019-04-23 12:16 ` Eli Zaretskii
2019-04-23 14:09 ` Michael Albinus
0 siblings, 1 reply; 7+ messages in thread
From: Eli Zaretskii @ 2019-04-23 12:16 UTC (permalink / raw)
To: Michael Albinus; +Cc: phst, emacs-devel
> From: Michael Albinus <michael.albinus@gmx.de>
> Cc: phst@google.com, emacs-devel@gnu.org
> Date: Tue, 23 Apr 2019 14:05:38 +0200
>
> The @code{:stderr} argument cannot be a pipe process, file name handlers
> do not support pipe processes for this. A buffer as @code{:stderr}
> argument is accepted, its contents is shown without the use of pipe processes.
SGTM, thanks.
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: master 3b4e312: Improve documentation around standard error pipes (Bug#35328).
2019-04-23 12:16 ` Eli Zaretskii
@ 2019-04-23 14:09 ` Michael Albinus
0 siblings, 0 replies; 7+ messages in thread
From: Michael Albinus @ 2019-04-23 14:09 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: phst, emacs-devel
Eli Zaretskii <eliz@gnu.org> writes:
>> The @code{:stderr} argument cannot be a pipe process, file name handlers
>> do not support pipe processes for this. A buffer as @code{:stderr}
>> argument is accepted, its contents is shown without the use of pipe processes.
>
> SGTM, thanks.
Pushed to master.
Best regards, Michael.
^ permalink raw reply [flat|nested] 7+ messages in thread
end of thread, other threads:[~2019-04-23 14:09 UTC | newest]
Thread overview: 7+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
[not found] <20190422140753.20611.97812@vcs0.savannah.gnu.org>
[not found] ` <20190422140756.5C1042088F@vcs0.savannah.gnu.org>
2019-04-22 20:59 ` master 3b4e312: Improve documentation around standard error pipes (Bug#35328) Michael Albinus
2019-04-23 5:45 ` Eli Zaretskii
2019-04-23 7:11 ` Michael Albinus
2019-04-23 10:28 ` Eli Zaretskii
2019-04-23 12:05 ` Michael Albinus
2019-04-23 12:16 ` Eli Zaretskii
2019-04-23 14:09 ` Michael Albinus
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).