bug-gnu-emacs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#30349: 27.0.50; Cuonfusing documentation about pipe processes


From: Eli Zaretskii
Subject: bug#30349: 27.0.50; Cuonfusing documentation about pipe processes
Date: Tue, 06 Feb 2018 05:54:43 +0200

> From: Noam Postavsky <npostavs@users.sourceforge.net>
> Date: Mon, 05 Feb 2018 19:53:12 -0500
> Cc: 30349@debbugs.gnu.org
> 
> > ":buffer BUFFER -- BUFFER is the buffer (or buffer-name) to associate
> > with the process.  Process output goes at the end of that buffer,
> > unless you specify an output stream or filter function to handle the
> > output."
> >
> > => How do you specify an output stream?
> 
> I don't think there is such a thing.  That phrase seems to have been
> copied across all the make-*-process functions.

And is wrong in all of them?

Could it be that the phrase originally meant shell-style redirection?

>  @item :stop @var{stopped}
> -If @var{stopped} is non-@code{nil}, start the process in the
> -stopped state.
> +If @var{stopped} is non-@code{nil}, start the process in the stopped
> +state.  In the stopped state, a pipe process does not accept incoming
> +data, but you can send outgoing data.  The stopped state is cleared by
> +@code{continue-process} and set by @code{stop-process}.

In the last sentence, I'd swap the order of references to clearing and
setting the stopped state.  I'd also add a @pxref to where those two
functions are described.

>  :buffer BUFFER -- BUFFER is the buffer (or buffer-name) to associate
> -with the process.  Process output goes at end of that buffer, unless
> -you specify an output stream or filter function to handle the output.
> -BUFFER may be also nil, meaning that this process is not associated
> -with any buffer.
> +with the process.  The default filter function writes process output
> +at the end of that buffer.  BUFFER may be also nil, meaning that this
> +process is not associated with any buffer.

This goes too far in deleting stuff that is useful: the part of the
second sentence that follows "unless", which talks about specifying a
filter function, should be left alone.  Without it, "The default
filter function ..." surprises the reader, since it talks about the
default of something that wasn't mentioned before.

With those fixed, this is good for the release branch, thanks.





reply via email to

[Prev in Thread] Current Thread [Next in Thread]