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.  */)