From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Jim Porter Newsgroups: gmane.emacs.devel Subject: Re: Eshell's external pipe module interferes with other argument parsing hooks Date: Thu, 31 Mar 2022 16:11:25 -0700 Message-ID: <0ac470ac-87e2-f3e9-7e23-28a6622ef082@gmail.com> References: <70677cd2-f741-16d1-b38f-c39b507cc95e@gmail.com> <871qyij7vx.fsf@melete.silentflame.com> <877d89iy53.fsf@melete.silentflame.com> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="27294"; mail-complaints-to="usenet@ciao.gmane.io" To: Sean Whitton , emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Fri Apr 01 01:12:05 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 1na3xU-0006wO-QF for ged-emacs-devel@m.gmane-mx.org; Fri, 01 Apr 2022 01:12:04 +0200 Original-Received: from localhost ([::1]:45604 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1na3xT-0006XA-A3 for ged-emacs-devel@m.gmane-mx.org; Thu, 31 Mar 2022 19:12:03 -0400 Original-Received: from eggs.gnu.org ([209.51.188.92]:46746) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1na3wu-0005rT-TL for emacs-devel@gnu.org; Thu, 31 Mar 2022 19:11:28 -0400 Original-Received: from [2607:f8b0:4864:20::102f] (port=41515 helo=mail-pj1-x102f.google.com) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1na3wt-0002sJ-9d for emacs-devel@gnu.org; Thu, 31 Mar 2022 19:11:28 -0400 Original-Received: by mail-pj1-x102f.google.com with SMTP id l4-20020a17090a49c400b001c6840df4a3so911177pjm.0 for ; Thu, 31 Mar 2022 16:11:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=subject:to:references:from:message-id:date:mime-version:in-reply-to :content-language:content-transfer-encoding; bh=XGLrHzuhNo9A+9FOwEw7cRiWTd7K+WAPok6YHC08+Yk=; b=pkEDXQEmd37QGT+0s04qJ478vDmLIaCXviLj322gkM8kFFfrGUxMuyBzzBiuCs0IXc QELfQdBspwG8xo3SpE6AHtQj0CHZjPY8RPKVWgzNoygZ/4Y24hn2fJs1RKfwXldeeyJP 17x4SYvqwKmowilPCtyKEmw8HfoywR5JOkhR6nFYb8F2cCl8FExiaVyaeaVU8eKBC/+U VsZLlF7+5NqbfEck1tvyniCkBthcYw2NJt0q5VrO8mAp9/l3tbtD9sF3xKd/q9Exj44W 9crkZWw4yZ0PhWgQ4cWTHczRrZ2E4fwkLzD9F+UT4t+K8qVU2D2/rJ/suAiky1D6S/x7 QFXg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:subject:to:references:from:message-id:date :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=XGLrHzuhNo9A+9FOwEw7cRiWTd7K+WAPok6YHC08+Yk=; b=qGcPaQ0aVmpWBn8ps3s6mefRSnHLPP2idNwUU6TzzsRUQ4drAMXv0LcI95UaG0jRtE zbaleAgrbF4lHSR4W4roKj995pHs128Svyw2ClY7vVfme1HmzKiReNqsXGKA2KOHLOB9 rvFb1ut5NlPEY08wPMZl+TrAMxRUYg2xRvvQPUzgXKjX/eOpVn/GLo9g9GtmlUz001Ab LEDg3X3uxp9l+Gw7FlURajRM9ut7KkPVVXRpYCTK4HcYT3Bg76ZhJbrUSoVz+UN3axlj 7AGzgAhTm6WEvJaewKjRa2BSVx/IgS3aXlw+vncllpfXlOmqnz3uYGjAsCG5xUlc76L3 SBbQ== X-Gm-Message-State: AOAM532hc5gvlc/2lrE/BUOk+/KbDo2fjZ0xzqM0TGzi1c4icNmR90lc CSkty5fwLW9u50h6jdWNs4JuJB9wliU= X-Google-Smtp-Source: ABdhPJw1du31lYoc4lEjnkgLiwKHn6Th8bj81Gn3ItZtVHpe+PTxRai/wUQ5Gd2ioRKbmJ+6ODKDnQ== X-Received: by 2002:a17:902:82c1:b0:155:ecb7:e018 with SMTP id u1-20020a17090282c100b00155ecb7e018mr7648915plz.59.1648768285675; Thu, 31 Mar 2022 16:11:25 -0700 (PDT) Original-Received: from [192.168.1.2] (cpe-76-168-148-233.socal.res.rr.com. [76.168.148.233]) by smtp.googlemail.com with ESMTPSA id 77-20020a621450000000b004fa923bb57asm509261pfu.201.2022.03.31.16.11.25 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 31 Mar 2022 16:11:25 -0700 (PDT) In-Reply-To: <877d89iy53.fsf@melete.silentflame.com> Content-Language: en-US X-Host-Lookup-Failed: Reverse DNS lookup failed for 2607:f8b0:4864:20::102f (failed) Received-SPF: pass client-ip=2607:f8b0:4864:20::102f; envelope-from=jporterbugs@gmail.com; helo=mail-pj1-x102f.google.com X-Spam_score_int: -6 X-Spam_score: -0.7 X-Spam_bar: / X-Spam_report: (-0.7 / 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, FREEMAIL_FROM=0.001, PDS_HP_HELO_NORDNS=0.659, RCVD_IN_DNSWL_NONE=-0.0001, RDNS_NONE=0.793, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01 autolearn=no 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:287649 Archived-At: On 3/31/2022 2:56 PM, Sean Whitton wrote: > 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. In practice, yes. However, the implementation could allow the other parsers to run, but then discard their parsed results during the rewrite phase if applicable. This is probably subject to a different set of unusual corner cases, but would allow other parsers to consume the parts of the command that they care about so that extpipe can just look for `*|' and friends. (A `*|' sequence inside quotes or something similar would already have been consumed by the time extpipe sees it.) >> 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. [snip] > > This could just be added to Eshell right now, right? Definitely useful. Unless there's a reason for Eshell's current behavior that I'm not aware of, I can't think of any problems with doing this, so long as everything is escaped properly. >> 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. For the purposes of parsing, having the token that activates the extpipe module be at the beginning of the relevant portion would make things a lot easier. Then `eshell-parse-external-pipeline' can just check if that's the next token and if so, read until the end of the extpipe portion. That would eliminate all the complexity of trying to identify unquoted/literal `*|' operators. In practice though, I'm happy with any syntax so long as the implementation is robust. If the current implementation using `*|' operators is significantly nicer to use (I don't have an opinion either way since I haven't used it enough), then we should stick with it, even if it makes it harder to implement. > 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 :) I'll try. :) I usually prefer shorter messages myself, but I've had a hard time finding the right balance on the Emacs lists. Sometimes I think I'm keeping things focused, only to find that I haven't relayed enough information, and instead have just confused matters. Splitting these threads off is probably the right call though. Thanks.