From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED.blaine.gmane.org!not-for-mail From: Michael Albinus Newsgroups: gmane.emacs.bugs Subject: bug#35055: 27.0.50; async-shell-command truncates output lines Date: Mon, 01 Apr 2019 12:00:15 +0200 Message-ID: <875zrym4eo.fsf@gmx.de> References: <87tvfkuivn.fsf@mail.linkov.net> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226"; logging-data="255333"; mail-complaints-to="usenet@blaine.gmane.org" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.0.50 (gnu/linux) Cc: 35055@debbugs.gnu.org To: Juri Linkov Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Mon Apr 01 12:01:18 2019 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([209.51.188.17]) by blaine.gmane.org with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1hAtkk-0014ES-4X for geb-bug-gnu-emacs@m.gmane.org; Mon, 01 Apr 2019 12:01:18 +0200 Original-Received: from localhost ([127.0.0.1]:46874 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1hAtki-0004VN-V1 for geb-bug-gnu-emacs@m.gmane.org; Mon, 01 Apr 2019 06:01:16 -0400 Original-Received: from eggs.gnu.org ([209.51.188.92]:52162) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1hAtkV-0004QY-Mq for bug-gnu-emacs@gnu.org; Mon, 01 Apr 2019 06:01:08 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1hAtkU-00027I-8U for bug-gnu-emacs@gnu.org; Mon, 01 Apr 2019 06:01:03 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:53539) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1hAtkT-00025l-W3 for bug-gnu-emacs@gnu.org; Mon, 01 Apr 2019 06:01:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1hAtkT-00006I-SO for bug-gnu-emacs@gnu.org; Mon, 01 Apr 2019 06:01:01 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Michael Albinus Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 01 Apr 2019 10:01:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 35055 X-GNU-PR-Package: emacs Original-Received: via spool by 35055-submit@debbugs.gnu.org id=B35055.1554112829325 (code B ref 35055); Mon, 01 Apr 2019 10:01:01 +0000 Original-Received: (at 35055) by debbugs.gnu.org; 1 Apr 2019 10:00:29 +0000 Original-Received: from localhost ([127.0.0.1]:38850 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1hAtjw-000059-SI for submit@debbugs.gnu.org; Mon, 01 Apr 2019 06:00:29 -0400 Original-Received: from mout.gmx.net ([212.227.17.22]:58453) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1hAtju-0008WV-Tg for 35055@debbugs.gnu.org; Mon, 01 Apr 2019 06:00:27 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=badeba3b8450; t=1554112817; bh=tr/hh3jt4sgN2nsKLCi9w1FFR+U3I+hJFMArlUXI32E=; h=X-UI-Sender-Class:From:To:Cc:Subject:References:Date:In-Reply-To; b=iOyBX2eC4rlqqioARqqtvLbOyXZMWKj6F2+hLahFtC5hYmcQBwaFqnNb9f08DY/VI T7eIiul9snMQtJkuThSLUX35mZC734J8xwP6JviIUK440dnYPeE89IsNs+Wnvn23JJ J36cN7f4l1DlEUbeXySjqgV5IJkeEp7TlE4aTxo0= X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c Original-Received: from detlef.gmx.de ([212.86.46.233]) by mail.gmx.com (mrgmx102 [212.227.17.168]) with ESMTPSA (Nemesis) id 0MTeVY-1hJauv1yEK-00QWEM; Mon, 01 Apr 2019 12:00:17 +0200 In-Reply-To: <87tvfkuivn.fsf@mail.linkov.net> (Juri Linkov's message of "Sat, 30 Mar 2019 23:55:56 +0200") X-Provags-ID: V03:K1:UJX+DsP+KUQENzPSwWgg+7rz64Cqb0ClwZxZyI3LbJg/cYTq+Wy xC408QS57MMVBccRfpWJ20cfTuWuClLN5fI3SkLo6gF64yKZVzoBXHUmxT7OaetF7QMYQEp Gl0ch9Z6QDRO3QR1T1momt4wI9Pc0Y0k3Mao9U7uytxoW0rxPE+jjUt0KGzUWo8/KdffZqo EwipgE+DX4DU/ESzeRy7A== X-UI-Out-Filterresults: notjunk:1;V03:K0:2AhhVNSOt4g=:6+TkWWK6CF72NYx793mdr3 xHd4jFWDRQqmHx3NP1dVuhIs4JGx0zbiDfBNcYOAQRWXZRHdrxJ3bC1Td4GuGH7by3dFrvTB9 VDTq+Le8KDaeD9v9EIAhnnl2LX7/5MP/X6hTU3VVS09fWL5KMbGd/c1JXBXu926q2Y1Bg9Z72 iF7PqO/pzSCLg+CNI4SQmIikNC7Foa2hOHqY5fWCl3Q6qLgsMUYwbtlBae9muOzIWKDMSac9P mK8EJWHyhxbADs4NVUZngVkfyO7qa2buq217jPLgG56aY0aRt3TCFGK6S/Lp8QHj+IxuSOCsA sMqDXb2yDiejqmPr4pqsbNnTNqgZ4V8zIuB6KrvTxNOBg0h2b9asXci0L2LrwYlk4C9Ayv2ta ZV+aR30rejPvF5Wd62OCI8Q5quxI9D4VVtcegKq1X0iY44UnA5AXlkV0esi7iUkeRpNGGztzT KYhGaKY/CNxfDThsRC7PtDzQIVBwGIemPPjNT8ZUp2NEVWoyR9KL1T8VRgO+7eTvYmRBc2WXi LmkfKsOH+JhFBzrTMGevV0FTgug4laUI6ZZtew/H6Vuw951/09x7pOjyl0whNXnkolAtjHXfU hTtlO8Qq87VpfJ6ACa0nDE8RIV5eH0I9Yr2hsMKKAuzMQL1k2Z4xlsxMNBshxaWcvS+LG8S09 goccuEDc2O3tftVRzM/SAZFDPvZTzzUdF14mk/hwtOAl4Ib7Gb9nt98zi+8kjKWj0owRvjy5M 0Y7f7pjsO2A6a2YSayejDUoiankhPIR1jJj3yMOy54S3IHCzrH3+0EWd8/Y9ye2l7mcMomCh X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 209.51.188.43 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.org@gnu.org Original-Sender: "bug-gnu-emacs" Xref: news.gmane.org gmane.emacs.bugs:157015 Archived-At: Juri Linkov writes: Hi Juri, > Test case: > > 1. Open a wide frame and type: > > 2. `M-& ps aux RET' > > 3. observe that output lines are truncated at column 80 In my case, output lines are truncated at column 89. In fact the truncation happens exactly at the size of the *Async Shell Command* buffer. > OTOH, there is no such problem with `M-! ps aux RET' > where lines are not truncated at all. > > So the question is: why `M-&' (async-shell-command) limits COLUMNS to 80, > even on wide frames, whereas `M-!' (shell-command) has no limitation. Internally, M-! uses `call-process', and M-& uses `start-file-process'. They have different implementations. Synchronous processes do not care about the buffer width. So you see untruncated output. Asynchronous processes care. They send the information about buffer dimensions with the function `set-process-window-size', see (info "(elisp) Process Buffers") There is the variable `window-adjust-process-window-size-function' which controls how the dimension information is given to the underlying process. I'm not sure whether there exists already a configuration option to allow asynchronous shell commands using infinite line width, but it could be implemented this way. Note that for remote shell commands the situation is even worse, because it sets the process property `adjust-window-size-function' to nil, overwriting any setting in `window-adjust-process-window-size-function'. This affects even synchronous `shell-command' calls, because they are implemented Tramp internally as asynchronous process. Best regards, Michael.