From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED.blaine.gmane.org!not-for-mail From: Juri Linkov Newsgroups: gmane.emacs.bugs Subject: bug#35055: 27.0.50; async-shell-command truncates output lines Date: Tue, 16 Apr 2019 23:39:41 +0300 Organization: LINKOV.NET Message-ID: <87mukpznua.fsf@mail.linkov.net> References: <87tvfkuivn.fsf@mail.linkov.net> <875zrym4eo.fsf@gmx.de> <877ecd797c.fsf@mail.linkov.net> <87y34s21vp.fsf@gmx.de> <87zhp6vmu5.fsf@mail.linkov.net> <87r2ah32rr.fsf@mail.linkov.net> <878swopr3p.fsf@gmx.de> <87y34mc13t.fsf@mail.linkov.net> <874l7ajmnx.fsf@gmx.de> <87lg0l1syw.fsf@mail.linkov.net> <87v9zpgd3t.fsf@gmx.de> <87mul0tfe5.fsf@mail.linkov.net> <87v9zib2vd.fsf@gmx.de> <877ebxa857.fsf@mail.linkov.net> <87a7gszd2q.fsf@gmx.de> <87sgukxu27.fsf@mail.linkov.net> <875zrfzp4m.fsf@gmx.de> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226"; logging-data="128579"; mail-complaints-to="usenet@blaine.gmane.org" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.0.50 (x86_64-pc-linux-gnu) Cc: 35055@debbugs.gnu.org To: Michael Albinus Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Tue Apr 16 22:55:19 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 1hGV6s-000XHE-AU for geb-bug-gnu-emacs@m.gmane.org; Tue, 16 Apr 2019 22:55:18 +0200 Original-Received: from localhost ([127.0.0.1]:42716 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1hGV6r-0005AQ-6o for geb-bug-gnu-emacs@m.gmane.org; Tue, 16 Apr 2019 16:55:17 -0400 Original-Received: from eggs.gnu.org ([209.51.188.92]:54124) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1hGV6g-00059o-N3 for bug-gnu-emacs@gnu.org; Tue, 16 Apr 2019 16:55:08 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1hGV6d-0008Db-Id for bug-gnu-emacs@gnu.org; Tue, 16 Apr 2019 16:55:04 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:52766) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1hGV6c-0008C8-Hp for bug-gnu-emacs@gnu.org; Tue, 16 Apr 2019 16:55:03 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1hGV6c-0002oy-Fm for bug-gnu-emacs@gnu.org; Tue, 16 Apr 2019 16:55:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Juri Linkov Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 16 Apr 2019 20:55:02 +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.155544806910790 (code B ref 35055); Tue, 16 Apr 2019 20:55:02 +0000 Original-Received: (at 35055) by debbugs.gnu.org; 16 Apr 2019 20:54:29 +0000 Original-Received: from localhost ([127.0.0.1]:38073 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1hGV63-0002nv-0W for submit@debbugs.gnu.org; Tue, 16 Apr 2019 16:54:27 -0400 Original-Received: from purple.birch.relay.mailchannels.net ([23.83.209.150]:39755) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1hGV60-0002nl-S7 for 35055@debbugs.gnu.org; Tue, 16 Apr 2019 16:54:25 -0400 X-Sender-Id: dreamhost|x-authsender|jurta@jurta.org Original-Received: from relay.mailchannels.net (localhost [127.0.0.1]) by relay.mailchannels.net (Postfix) with ESMTP id 97F2B2C0F14; Tue, 16 Apr 2019 20:54:20 +0000 (UTC) Original-Received: from pdx1-sub0-mail-a29.g.dreamhost.com (100-96-7-60.trex.outbound.svc.cluster.local [100.96.7.60]) (Authenticated sender: dreamhost) by relay.mailchannels.net (Postfix) with ESMTPA id DEC882C2333; Tue, 16 Apr 2019 20:54:19 +0000 (UTC) X-Sender-Id: dreamhost|x-authsender|jurta@jurta.org Original-Received: from pdx1-sub0-mail-a29.g.dreamhost.com ([TEMPUNAVAIL]. [64.90.62.162]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384) by 0.0.0.0:2500 (trex/5.17.2); Tue, 16 Apr 2019 20:54:20 +0000 X-MC-Relay: Neutral X-MailChannels-SenderId: dreamhost|x-authsender|jurta@jurta.org X-MailChannels-Auth-Id: dreamhost X-Bitter-Callous: 01f13a4c742dc435_1555448060405_168926174 X-MC-Loop-Signature: 1555448060405:3790954056 X-MC-Ingress-Time: 1555448060404 Original-Received: from pdx1-sub0-mail-a29.g.dreamhost.com (localhost [127.0.0.1]) by pdx1-sub0-mail-a29.g.dreamhost.com (Postfix) with ESMTP id C9574804B1; Tue, 16 Apr 2019 13:54:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=linkov.net; h=from:to:cc :subject:references:date:in-reply-to:message-id:mime-version :content-type; s=linkov.net; bh=EwwaDWiC0cTm9FEM51p1I2k7h6I=; b= hN4XtBCURlTEiTyteawxJ+/FjkBoUD6GgKcu4hIi5TC2D1vEk8BIdmpJ+AEb23lf BlDbtxTrVK5r3CeeVm8g8bIguCPrvN9kKtMb/8Ta/Zchu9H9DwBDTpVkzhXOA+Qz EVJ+E6w8/BIXOu/1JIMaH00N0BAYMDNup688ISU2ums= Original-Received: from mail.jurta.org (m91-129-111-111.cust.tele2.ee [91.129.111.111]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) (Authenticated sender: jurta@jurta.org) by pdx1-sub0-mail-a29.g.dreamhost.com (Postfix) with ESMTPSA id 1FDE4804B4; Tue, 16 Apr 2019 13:54:14 -0700 (PDT) X-DH-BACKEND: pdx1-sub0-mail-a29 In-Reply-To: <875zrfzp4m.fsf@gmx.de> (Michael Albinus's message of "Mon, 15 Apr 2019 09:47:21 +0200") X-VR-OUT-STATUS: OK X-VR-OUT-SCORE: -100 X-VR-OUT-SPAMCAUSE: gggruggvucftvghtrhhoucdtuddrgeduuddrfedugdduheegucetufdoteggodetrfdotffvucfrrhhofhhilhgvmecuggftfghnshhusghstghrihgsvgdpffftgfetoffjqffuvfenuceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmnecujfgurhephffvufhofhffjgfkfgggtgesthdtredttdertdenucfhrhhomheplfhurhhiucfnihhnkhhovhcuoehjuhhriheslhhinhhkohhvrdhnvghtqeenucfkphepledurdduvdelrdduuddurdduuddunecurfgrrhgrmhepmhhouggvpehsmhhtphdphhgvlhhopehmrghilhdrjhhurhhtrgdrohhrghdpihhnvghtpeeluddruddvledrudduuddrudduuddprhgvthhurhhnqdhprghthheplfhurhhiucfnihhnkhhovhcuoehjuhhriheslhhinhhkohhvrdhnvghtqedpmhgrihhlfhhrohhmpehjuhhriheslhhinhhkohhvrdhnvghtpdhnrhgtphhtthhopehmihgthhgrvghlrdgrlhgsihhnuhhssehgmhigrdguvgenucevlhhushhtvghrufhiiigvpedt 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:157739 Archived-At: >>> Thanks. However, I've meant this also for synchronous >>> `shell-command'. You have implemented this only for asynchronous. >>> >>> The synchronous `shell-command' does not suffer from the buffer width >>> restriction. But there might be use cases to set a fixed width, for >>> example if you want to get a well-defined output layout. >> >> Oh, I don't know what to do in case when only the current limit >> on the output of asynchronous commands should be increased, but >> the output of synchronous commands needs to be left unlimited. >> I have no idea how to customize it in this case. > > I don't believe there is a conflict. The main use case will be to > increase the output width of a shell command, in order not to loose > information. People will do this by setting a large value, say > 1024. This will be used for both the synchronous and asynchronous case. The same value will increase the output width of async shell commands, but decrease the output width of synchronous shell commands from unlimited. > And then there's the use case to have a fixed output width for special > commands, in order to get a deterministic layout. This won't be applied > globally, neither for synchronous nor for asynchronous > `shell-command'. Rather, `shell-command-width' will be let-bound. > > And we have the advantage, that synchronous `shell-command' behaves > consistently, for both the local and remote case. > > So I don't see a problem. If output truncation will apply to shell-command-on-region, especially with its REPLACE arg, this would be a big problem. After filtering the buffer contents with a shell command, parts of the buffer will be lost.