From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Sean Whitton Newsgroups: gmane.emacs.devel Subject: Re: Eshell's external pipe module interferes with other argument parsing hooks Date: Thu, 31 Mar 2022 14:56:56 -0700 Message-ID: <877d89iy53.fsf@melete.silentflame.com> References: <70677cd2-f741-16d1-b38f-c39b507cc95e@gmail.com> <871qyij7vx.fsf@melete.silentflame.com> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="31307"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Emacs/29.0.50 (x86_64-pc-linux-gnu) To: Jim Porter , emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Thu Mar 31 23:57:39 2022 Return-path: Envelope-to: ged-emacs-devel@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 1na2nR-0007o4-UY for ged-emacs-devel@m.gmane-mx.org; Thu, 31 Mar 2022 23:57:39 +0200 Original-Received: from localhost ([::1]:60572 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1na2nQ-0006el-Fp for ged-emacs-devel@m.gmane-mx.org; Thu, 31 Mar 2022 17:57:36 -0400 Original-Received: from eggs.gnu.org ([209.51.188.92]:33278) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1na2mq-0005yi-TD for emacs-devel@gnu.org; Thu, 31 Mar 2022 17:57:00 -0400 Original-Received: from out4-smtp.messagingengine.com ([66.111.4.28]:56257) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1na2mp-0005oE-2R for emacs-devel@gnu.org; Thu, 31 Mar 2022 17:57:00 -0400 Original-Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailout.nyi.internal (Postfix) with ESMTP id 7E5325C01AA; Thu, 31 Mar 2022 17:56:57 -0400 (EDT) Original-Received: from mailfrontend1 ([10.202.2.162]) by compute4.internal (MEProxy); Thu, 31 Mar 2022 17:56:57 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=spwhitton.name; h=cc:content-type:date:date:from:from:in-reply-to:in-reply-to :message-id:mime-version:references:reply-to:sender:subject :subject:to:to; s=fm3; bh=ln0mknziXdeiWqjNcg1kyN/NeFfUrUWoP3vr3w OxtRw=; b=kUZ4orvI5qQy5EHcEMPWUozssv/nMDNQQHgCxanR8ueyou7VJ7sdEO R8XwYPFpA66OPEuzylLFvNTRZsSLZdecdhqfWUmAPTYRiDBdf8pPrSKwM51hSrC4 6t/1P1SSfGybaDBYZhPPIsSeUIBCHABBQVrUSS0C/xkdVPEx306HLkNh3BaDl+pf u14WNFgvGxf6fbJuugH8ZJdLoIoxu2j8xKVAwUOrEqiKTEuus1WmwvHmS+1hwMKh xzqLk7K18gLKPdAw/NNInXGKqGS8wc3mDv1OP8Z4Ne1yhDOnpDZRBg/cCXGLSrIj oFNgZwg8GowQQILMi5vNqcDXYe5Dk/kQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-type:date:date:from:from :in-reply-to:in-reply-to:message-id:mime-version:references :reply-to:sender:subject:subject:to:to:x-me-proxy:x-me-proxy :x-me-sender:x-me-sender:x-sasl-enc; s=fm3; bh=ln0mknziXdeiWqjNc g1kyN/NeFfUrUWoP3vr3wOxtRw=; b=FwIIx6rnRnpUMMFU+6zDK7QLu4bouIzCQ hpH4r4QdmUwG7YiWwzbJpRHZtVIJGbQs3gSku3bVMYAqbUaFcOj7hLSq+VnheMHl UIUsBgVZJJf6vSH19EMeaGFpvx2EpGZft4i4OnVM7td+mTBb09aXqoe4OenZBjgl KRj9eCiEmL6BHxE0KgjTs3QcyZ77SIg9QG8pAnHitP2ATqWHqa2GSYdXYEnmH/li uRiTVc4jE/ONBu0nqm1iDFkw5vD4K2Keq3unKxRKdCNh7gMAxaZv2D6b4dXgLWdn /VItpsB/8CWJYX7bxIbcXey8566AQPUd5rfdL6OAi3V25kBVvp0RA== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvvddrudeihedgtdefucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucenucfjughrpefhvffujghffgffkfggtgesthdttd dttdertdenucfhrhhomhepufgvrghnucghhhhithhtohhnuceoshhpfihhihhtthhonhes shhpfihhihhtthhonhdrnhgrmhgvqeenucggtffrrghtthgvrhhnpeelgeeggfdvieejvd fhudfggeetgfekkeeuieeljeejhedugeegfeetgefhueffkeenucevlhhushhtvghrufhi iigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpehsphifhhhithhtohhnsehsphifhh hithhtohhnrdhnrghmvg X-ME-Proxy: Original-Received: by mail.messagingengine.com (Postfix) with ESMTPA; Thu, 31 Mar 2022 17:56:57 -0400 (EDT) Original-Received: by melete.silentflame.com (Postfix, from userid 1000) id BEC4E7E1317; Thu, 31 Mar 2022 14:56:56 -0700 (MST) In-Reply-To: Received-SPF: pass client-ip=66.111.4.28; envelope-from=spwhitton@spwhitton.name; helo=out4-smtp.messagingengine.com X-Spam_score_int: -27 X-Spam_score: -2.8 X-Spam_bar: -- X-Spam_report: (-2.8 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.io gmane.emacs.devel:287647 Archived-At: [switching debbugs -> emacs-devel for this subthread] Hello, On Thu 31 Mar 2022 at 01:58PM -07, Jim Porter wrote: > Another possibility would be to keep the current behavior (or close to > it), but to reconstruct the command to pass to `sh' during Eshell's > rewrite phase. I'm not quite sure if that would actually work, but if it > did, it would allow other argument parsers to run normally without > extpipe needing to know what parsers to try. Perhaps if we kept around > the substring that each argument parser consumed, it would be possible > to reconstruct the relevant bits for extpipe's purposes? Well, in your case (2), you don't want the other parsers to get a chance to run -- that's the whole point. > More generally though, maybe there are really two different use cases? > > 1) Eshell's built-in pipelines are slow because they go through Emacs > buffers. > > 2) It would be convenient to invoke a whole command (or some large part > of a command) using `sh' syntax. These are both things that extpipe is meant to make easy, though I'm not sure how separate they are -- often I want both. > For (1), Eshell could opportunistically use external pipelines without > any special syntax. It should be possible to tell just by looking at the > parsed command form if "foo | bar" connects two external processes on > the same host, and then perform the appropriate rewrite to connect the > processes efficiently (e.g. using `sh -c'). This would happen after > expansion of variables/subcommands, so to the user it would work just > like any other Eshell command, but it would be faster. This could just be added to Eshell right now, right? Definitely useful. > For (2), we'd need a convenient syntax for forwarding some command > string to `sh'. Something like your proposed !! or || syntax, or maybe > something to wrap around part of a command? Yeah, extpipe's syntax covers most such cases but not quite all of them. > (Or maybe an even something like an interactive `eshell-externalize' > function that replaces the selected region with the correct `sh' > invocation?) I had something like this previously. The problem is it makes editing and re-running the command a fair bit more fiddly. > And finally, sorry for bringing up these issues months after > bug#46351. At the time, I didn't really understand the internals of > Eshell, so I didn't have anything of substance to say then. Since then > I've delved a bit *too* deep into Eshell's internals while trying to > prove to myself that my implementation of Lisp function pipelines is > sufficiently-flexible. :) No problem, but could I request that you spend a little more time editing your messages for length? And perhaps consider separating out discussion of significant future possible enhancements from fixing bugs with the existing code into separate bugs or ML threads, as I've done with this message. Thanks in advance :) -- Sean Whitton