bug#33191: 26.1.50; remove remaining process input batching doc

bug#33191: 26.1.50; remove remaining process input batching doc

[Charles A. Roelli]

(as discussed in Bug#33050#116)

- Remove mention of "stray character injections" in Elisp node
  "Asynchronous Processes".
- Remove doc of "process-send-string" and "process-send-region" 
  claiming to split process input every 500 characters.

bug#33191: 26.1.50; remove remaining process input batching doc

[Charles A. Roelli]

> Date: Sun, 28 Oct 2018 20:52:34 +0100
> From: charles@aurox.ch (Charles A. Roelli)
> 
> (as discussed in Bug#33050#116)
> 
> - Remove mention of "stray character injections" in Elisp node
>   "Asynchronous Processes".
> - Remove doc of "process-send-string" and "process-send-region" 
>   claiming to split process input every 500 characters.

Here's a suggested change for emacs-26:

diff --git a/doc/lispref/processes.texi b/doc/lispref/processes.texi
index e7d61bd..623be09 100644
--- a/doc/lispref/processes.texi
+++ b/doc/lispref/processes.texi
@@ -604,10 +604,9 @@ Asynchronous Processes
 internal purposes (i.e., no user interaction with the subprocess is
 required), where significant amounts of data need to be exchanged
 between the subprocess and the Lisp program, it is often better to use
-a pipe, because pipes are more efficient, and because they are immune
-to stray character injections that ptys introduce for large (around
-500 byte) messages.  Also, the total number of ptys is limited on many
-systems, and it is good not to waste them unnecessarily.
+a pipe, because pipes are more efficient.  Also, the total number of
+ptys is limited on many systems, and it is good not to waste them
+unnecessarily.
 
 @defun make-process &rest args
 This function is the basic low-level primitive for starting
diff --git a/src/process.c b/src/process.c
index b0a3272..90e0f64 100644
--- a/src/process.c
+++ b/src/process.c
@@ -6456,9 +6456,6 @@ DEFUN ("process-send-region", Fprocess_send_region, Sprocess_send_region,
 PROCESS may be a process, a buffer, the name of a process or buffer, or
 nil, indicating the current buffer's process.
 Called from program, takes three arguments, PROCESS, START and END.
-If the region is more than 500 characters long,
-it is sent in several bunches.  This may happen even for shorter regions.
-Output from processes can arrive in between bunches.
 
 If PROCESS is a non-blocking network process that hasn't been fully
 set up yet, this function will block until socket setup has completed.  */)
@@ -6489,9 +6486,6 @@ DEFUN ("process-send-string", Fprocess_send_string, Sprocess_send_string,
        doc: /* Send PROCESS the contents of STRING as input.
 PROCESS may be a process, a buffer, the name of a process or buffer, or
 nil, indicating the current buffer's process.
-If STRING is more than 500 characters long,
-it is sent in several bunches.  This may happen even for shorter strings.
-Output from processes can arrive in between bunches.
 
 If PROCESS is a non-blocking network process that hasn't been fully
 set up yet, this function will block until socket setup has completed.  */)

bug#33191: 26.1.50; remove remaining process input batching doc

[Eli Zaretskii]

> Date: Sun, 09 Dec 2018 11:45:26 +0100
> From: charles@aurox.ch (Charles A. Roelli)
> Cc: 33191@debbugs.gnu.org
> 
> > Date: Sun, 28 Oct 2018 20:52:34 +0100
> > From: charles@aurox.ch (Charles A. Roelli)
> > 
> > (as discussed in Bug#33050#116)
> > 
> > - Remove mention of "stray character injections" in Elisp node
> >   "Asynchronous Processes".
> > - Remove doc of "process-send-string" and "process-send-region" 
> >   claiming to split process input every 500 characters.
> 
> Here's a suggested change for emacs-26:

Thanks, but this removes too much, IMO.  The 500 bytes figure should
go away, but we still send the string in chunks, albeit
system-dependent ones, and we still allow output from processes to
arrive between chunks.

bug#33191: 26.1.50; remove remaining process input batching doc

[Charles A. Roelli]

> Date: Sun, 09 Dec 2018 14:47:54 +0200
> From: Eli Zaretskii <eliz@gnu.org>
>
> Thanks, but this removes too much, IMO.  The 500 bytes figure should
> go away, but we still send the string in chunks, albeit
> system-dependent ones, and we still allow output from processes to
> arrive between chunks.

True, but it seems like chunked sending is broken somehow: Bug#6149
(GNU/Linux) and Bug#32438 (macOS) both show this.  (There may be
similar problems on MS Windows; I have not tested.)  If we say that
sending is done in chunks, users might infer that there are no such
problems.  Maybe we can add that system-dependent problems may occur
for input longer than 1 kB.

bug#33191: 26.1.50; remove remaining process input batching doc

[Eli Zaretskii]

> Date: Sun, 09 Dec 2018 17:15:49 +0100
> From: charles@aurox.ch (Charles A. Roelli)
> CC: 33191@debbugs.gnu.org
> 
> > Date: Sun, 09 Dec 2018 14:47:54 +0200
> > From: Eli Zaretskii <eliz@gnu.org>
> >
> > Thanks, but this removes too much, IMO.  The 500 bytes figure should
> > go away, but we still send the string in chunks, albeit
> > system-dependent ones, and we still allow output from processes to
> > arrive between chunks.
> 
> True, but it seems like chunked sending is broken somehow: Bug#6149
> (GNU/Linux) and Bug#32438 (macOS) both show this.

The former is supposed to be solved.

> (There may be similar problems on MS Windows; I have not tested.)
> If we say that sending is done in chunks, users might infer that
> there are no such problems.

I don't see how such a conclusion could follow.  IMO, it's important
to tell that we send large strings in smaller chunks, because
otherwise some phenomena might come as a surprise.

> Maybe we can add that system-dependent problems may occur for input
> longer than 1 kB.

I don't think we should document bugs.  We should solve them instead.

bug#33191: 26.1.50; remove remaining process input batching doc

[Charles A. Roelli]

> Date: Sun, 09 Dec 2018 18:32:44 +0200
> From: Eli Zaretskii <eliz@gnu.org>
> CC: 33191@debbugs.gnu.org
>
> > True, but it seems like chunked sending is broken somehow: Bug#6149
> > (GNU/Linux) and Bug#32438 (macOS) both show this.
> 
> The former is supposed to be solved.

I re-opened it at the end of September, I think.

> > (There may be similar problems on MS Windows; I have not tested.)
> > If we say that sending is done in chunks, users might infer that
> > there are no such problems.
> 
> I don't see how such a conclusion could follow.  IMO, it's important
> to tell that we send large strings in smaller chunks, because
> otherwise some phenomena might come as a surprise.

Fair enough.  Maybe I've confused the "chunk" issue with the issue of
sending large strings, which might not always be related.

> > Maybe we can add that system-dependent problems may occur for input
> > longer than 1 kB.
> 
> I don't think we should document bugs.  We should solve them instead.

Okay.  In the meantime, how about the following amended change?  It
replaces the "500 character" limit with the idea of the "input buffer"
limit (which is itself dependent on the process connection type and
the OS).


diff --git a/doc/lispref/processes.texi b/doc/lispref/processes.texi
index e7d61bd..623be09 100644
--- a/doc/lispref/processes.texi
+++ b/doc/lispref/processes.texi
@@ -604,10 +604,9 @@ Asynchronous Processes
 internal purposes (i.e., no user interaction with the subprocess is
 required), where significant amounts of data need to be exchanged
 between the subprocess and the Lisp program, it is often better to use
-a pipe, because pipes are more efficient, and because they are immune
-to stray character injections that ptys introduce for large (around
-500 byte) messages.  Also, the total number of ptys is limited on many
-systems, and it is good not to waste them unnecessarily.
+a pipe, because pipes are more efficient.  Also, the total number of
+ptys is limited on many systems, and it is good not to waste them
+unnecessarily.
 
 @defun make-process &rest args
 This function is the basic low-level primitive for starting
diff --git a/src/process.c b/src/process.c
index b0a3272..e306b2a 100644
--- a/src/process.c
+++ b/src/process.c
@@ -6456,9 +6456,11 @@ DEFUN ("process-send-region", Fprocess_send_region, Sprocess_send_region,
 PROCESS may be a process, a buffer, the name of a process or buffer, or
 nil, indicating the current buffer's process.
 Called from program, takes three arguments, PROCESS, START and END.
-If the region is more than 500 characters long,
-it is sent in several bunches.  This may happen even for shorter regions.
-Output from processes can arrive in between bunches.
+If the region is larger than the input buffer of the process (the
+length of which depends on the process connection type and the
+operating system), it is sent in several bunches.  This may happen
+even for shorter regions.  Output from processes can arrive in between
+bunches.
 
 If PROCESS is a non-blocking network process that hasn't been fully
 set up yet, this function will block until socket setup has completed.  */)
@@ -6489,9 +6491,10 @@ DEFUN ("process-send-string", Fprocess_send_string, Sprocess_send_string,
        doc: /* Send PROCESS the contents of STRING as input.
 PROCESS may be a process, a buffer, the name of a process or buffer, or
 nil, indicating the current buffer's process.
-If STRING is more than 500 characters long,
-it is sent in several bunches.  This may happen even for shorter strings.
-Output from processes can arrive in between bunches.
+If STRING is larger than the input buffer of the process (the length
+of which depends on the process connection type and the operating
+system), it is sent in several bunches.  This may happen even for
+shorter strings.  Output from processes can arrive in between bunches.
 
 If PROCESS is a non-blocking network process that hasn't been fully
 set up yet, this function will block until socket setup has completed.  */)

bug#33191: 26.1.50; remove remaining process input batching doc

[Eli Zaretskii]

> Date: Sun, 09 Dec 2018 20:24:35 +0100
> From: charles@aurox.ch (Charles A. Roelli)
> CC: 33191@debbugs.gnu.org
> 
> Okay.  In the meantime, how about the following amended change?  It
> replaces the "500 character" limit with the idea of the "input buffer"
> limit (which is itself dependent on the process connection type and
> the OS).

LGTM, thanks.

bug#33191: 26.1.50; remove remaining process input batching doc

[Charles A. Roelli]

tags 33191 fixed
close 33191 26.2
quit

> Date: Sat, 22 Dec 2018 12:53:29 +0200
> From: Eli Zaretskii <eliz@gnu.org>
>
> > Okay.  In the meantime, how about the following amended change?  It
> > replaces the "500 character" limit with the idea of the "input buffer"
> > limit (which is itself dependent on the process connection type and
> > the OS).
> 
> LGTM, thanks.

Thanks, it's pushed to emacs-26.