From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.bugs Subject: bug#6149: bug#24531: process-send-string seems to truncate lines over 4096 characters Date: Fri, 21 Jul 2023 08:39:52 +0300 Message-ID: <83sf9h257b.fsf@gnu.org> References: <87aas81jgh.fsf@jidanni.org> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="34875"; mail-complaints-to="usenet@ciao.gmane.io" Cc: 24531@debbugs.gnu.org, sbaugh@janestreet.com, 6149@debbugs.gnu.org, jidanni@jidanni.org To: Stefan Monnier Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Fri Jul 21 07:40:31 2023 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1qMisR-0008uU-M0 for geb-bug-gnu-emacs@m.gmane-mx.org; Fri, 21 Jul 2023 07:40:31 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1qMisK-0003xr-Nj; Fri, 21 Jul 2023 01:40:24 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1qMirz-0003wf-9b for bug-gnu-emacs@gnu.org; Fri, 21 Jul 2023 01:40:03 -0400 Original-Received: from debbugs.gnu.org ([2001:470:142:5::43]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1qMirz-000442-0I for bug-gnu-emacs@gnu.org; Fri, 21 Jul 2023 01:40:03 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1qMiry-0001ub-SK for bug-gnu-emacs@gnu.org; Fri, 21 Jul 2023 01:40:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Fri, 21 Jul 2023 05:40:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 6149 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: confirmed Original-Received: via spool by 6149-submit@debbugs.gnu.org id=B6149.16899179917312 (code B ref 6149); Fri, 21 Jul 2023 05:40:02 +0000 Original-Received: (at 6149) by debbugs.gnu.org; 21 Jul 2023 05:39:51 +0000 Original-Received: from localhost ([127.0.0.1]:60360 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qMirm-0001tr-S0 for submit@debbugs.gnu.org; Fri, 21 Jul 2023 01:39:51 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:47488) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qMirh-0001tW-Vf; Fri, 21 Jul 2023 01:39:49 -0400 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1qMira-00040D-6a; Fri, 21 Jul 2023 01:39:38 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date: mime-version; bh=sz40LrDqf2E8EDxiFG/QQ/yAFYZH/VZlTh3SqEsZETw=; b=GlFGdWbA/Ghc kiWCE/SU1GXlx3XAAyb3zfoTQjZM89KoUYKx7UDwdvGK9xssseMwNZhwVuSXtmnXV9nJr54yUc36s zHHIFbMkHYecntBXxkOkiBXpW8Y5DGFEXVYryCjFdhAwDIYf2cWeUZkUVjFCGE741M80vKrIynjAg MBkqZJr9HLb0z/MigmkvDnc6GyTkSPK79AwSjRVMGqeec3Ay1OuXvs1m7wDjVndTFyo1GDPZXNZv9 gZ9XrQumTSwtg4DfH9/F1+5vss2gFawx0Jtp1QhxoOlggcxE3LOVgVEIX04AYRou1no1K7pv0T49t Stc9hNm+VciPu3HmtIY3vA==; Original-Received: from [87.69.77.57] (helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1qMirF-0000B9-CM; Fri, 21 Jul 2023 01:39:31 -0400 In-Reply-To: (bug-gnu-emacs@gnu.org) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.bugs:265650 Archived-At: > Cc: 24531@debbugs.gnu.org, 6149@debbugs.gnu.org, jidanni@jidanni.org > Date: Thu, 20 Jul 2023 17:21:53 -0400 > From: Stefan Monnier via "Bug reports for GNU Emacs, > the Swiss army knife of text editors" > > > I see that this bug is about 13 years old. I think there's a pretty > > obvious solution: process-connection-type should default to nil. > > In practice, that can't fly because it'll break existing code. Indeed. A large portion (I think the majority, but I'm not sure) of Lisp programs that use bidirectional communications with async subprocesses actually _want_ the PTY interface, because they act as GUI front-ends to other programs. Think "M-x term", "M-x gdb", inferior-python-mode, etc. Even "M-x grep" and the likes need that because they rely on default color output, which only happens if Grep is connected to a terminal device. Some of the Emacs features based on this don't work or don't work well on MS-Windows because Windows only supports pipes. Do we really want such semi-broken behavior on GNU and Unix systems? 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. > Also I don't think either value of `process-connection-type` is a good > option. IOW, I think that the connection type should be a mandatory > argument when creating an async process (except maybe for those > processes with no input/output). If we go that way, we should start by specifying :connection-type for all the uses of make-process and start-process we have in the core. It's a large job, but before it is done we cannot in good faith make such an incompatible transition. > So maybe, the default value of `process-connection-type` should be > `unspecified` and the process creation code should emit a warning when > creating a process whose connection type is `unspecified` (just > a warning, tho: it should then pursue execution as if that value was t, > as usual, so as to preserve compatibility). Something like that, yes. But I'm actually wondering how come modern Linux kernels don't have a way of lifting this restriction, or at least enlarging the limit so it makes the problem even less frequent. Is there some inherent limitation that this must be 4KB and nothing larger?