all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: Eli Zaretskii <eliz@gnu.org>
To: Spencer Baugh <sbaugh@janestreet.com>
Cc: 24531@debbugs.gnu.org, 6149@debbugs.gnu.org,
	monnier@iro.umontreal.ca, jidanni@jidanni.org
Subject: bug#24531: process-send-string seems to truncate lines over 4096 characters
Date: Fri, 21 Jul 2023 17:18:34 +0300	[thread overview]
Message-ID: <83edl1bb5x.fsf@gnu.org> (raw)
In-Reply-To: <ieredl1v01d.fsf_-_@janestreet.com> (message from Spencer Baugh on Fri, 21 Jul 2023 09:58:38 -0400)

> From: Spencer Baugh <sbaugh@janestreet.com>
> Cc: Stefan Monnier <monnier@iro.umontreal.ca>,  24531@debbugs.gnu.org,
>    6149@debbugs.gnu.org,  jidanni@jidanni.org
> Date: Fri, 21 Jul 2023 09:58:38 -0400
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > The number of applications that (a) don't need console-like behavior
> > and (b) need to send larger-than-4KB buffers to sub-processes is quite
> > small.  Which is why this issue comes up only very rarely.  So making
> > pipes the default will fix a very small fraction of applications, and
> > break the vast majority -- clearly a wrong balance.
> 
> I see your point, but at the same time, the PTY interface on its own is
> not sufficient to make these applications work, not at all.  Specialized
> modes are necessary to make M-x term (to implement a terminal) and M-x
> grep (to parse ANSI color codes) and other such programs work.  Running
> things in a PTY without such specialized code doesn't give you anything,
> AFAIK, because a PTY alone is far from enough to make the Emacs end
> behave like a terminal.  So such programs need to be aware and careful
> about such things anyway, and need additional infrastructure on top of
> make-process.  So the default being "pty" gives such programs very
> little: it doesn't save them any complexity.

That Emacs needs to do something doesn't invalidate my point.  My
point is that communications via a PTY is a necessary (though a
sufficient) condition for these features.  Basically, you cannot use
pipes for any interactive feature, because pipes are buffered.

> However, what about my patch adding a warning about this to
> process-send-string?  I think that is independently valuable.  Right now
> we have no documentation of this problem...

This should be documented in the ELisp manual, and in more detail, not
just as a vague warning.





  reply	other threads:[~2023-07-21 14:18 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-05-10  4:14 bug#6149: 24.0.50; shell buffer overflow when input longer than 4096 bytes jidanni
2010-06-01  1:50 ` Stefan Monnier
2023-07-20 20:15   ` bug#6149: bug#24531: process-send-string seems to truncate lines over 4096 characters Spencer Baugh
2023-07-20 21:21     ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-07-21  5:39       ` Eli Zaretskii
2023-07-21 13:58         ` Spencer Baugh
2023-07-21 14:18           ` Eli Zaretskii [this message]
2023-07-27  1:48           ` bug#6149: " Dmitry Gutov
2023-07-27  5:41             ` Eli Zaretskii
2023-07-27 13:59               ` Spencer Baugh
2023-07-27 14:51                 ` Paul Eggert
2023-07-21 15:09         ` bug#24531: " Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2018-09-28 20:13 ` bug#6149: 24.0.50; shell buffer overflow when input longer than 4096 bytes Charles A. Roelli
  -- strict thread matches above, loose matches on Subject: below --
2016-09-24 23:38 bug#24531: process-send-string seems to truncate lines over 4096 characters talwrii talwrii
2016-09-26  8:36 ` Thien-Thi Nguyen
2016-09-26 10:23   ` Andreas Schwab

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=83edl1bb5x.fsf@gnu.org \
    --to=eliz@gnu.org \
    --cc=24531@debbugs.gnu.org \
    --cc=6149@debbugs.gnu.org \
    --cc=jidanni@jidanni.org \
    --cc=monnier@iro.umontreal.ca \
    --cc=sbaugh@janestreet.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this external index

	https://git.savannah.gnu.org/cgit/emacs.git
	https://git.savannah.gnu.org/cgit/emacs/org-mode.git

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.