From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=-1.0 required=5.0 tests=MAILING_LIST_MULTI, RCVD_IN_DNSWL_NONE autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 13115 invoked from network); 17 May 2020 22:12:58 -0000 Received: from ns1.primenet.com.au (HELO primenet.com.au) (203.24.36.2) by inbox.vuxu.org with ESMTPUTF8; 17 May 2020 22:12:58 -0000 Received: (qmail 12767 invoked by alias); 17 May 2020 22:12:50 -0000 Mailing-List: contact zsh-users-help@zsh.org; run by ezmlm Precedence: bulk X-No-Archive: yes List-Id: Zsh Users List List-Post: List-Help: List-Unsubscribe: X-Seq: 24849 Received: (qmail 5343 invoked by uid 1010); 17 May 2020 22:12:50 -0000 X-Qmail-Scanner-Diagnostics: from mail-ot1-f45.google.com by f.primenet.com.au (envelope-from , uid 7791) with qmail-scanner-2.11 (clamdscan: 0.102.3/25814. spamassassin: 3.4.4. Clear:RC:0(209.85.210.45):SA:0(-1.9/5.0):. Processed in 1.857507 secs); 17 May 2020 22:12:50 -0000 X-Envelope-From: schaefer@brasslantern.com X-Qmail-Scanner-Mime-Attachments: | X-Qmail-Scanner-Zip-Files: | Received-SPF: pass (ns1.primenet.com.au: SPF record at _netblocks.google.com designates 209.85.210.45 as permitted sender) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=FniDuGYvlik6DlcBVBCFyugn0aVZ0zEjKKuQId/17jY=; b=sxOl2TirtQ//FyYmfyzC/2YXoDnt0B4Z/LVvRmr4hIzn9QEOAosF76JN6Pa0Y3pE6h XQBm0mYNEvxbbIEnLkp6mdE3EWINBDtMQFJAoIJAO9j2K6gnCqjrhB62CBr7BHmKhV68 7m84iIbIHltMHzUmy+aEY9hjbqFm4YSRkQHMqokonbTKG9IOzu2EEGwjHeeCG8aIETmw Lgl+EoL+YsMQ4/DvpjKWc0uPNB2+U7LdaiI31mDLsFbsrEY6yMfRcTYgQHutM5Wg8KYt 53RNxzpo/NipRbEE0TMeUqm8IuuRb3ZtmkOBKQKm5MtVIKVIUPjg0J9pVsshmN9sYmo4 lvgg== X-Gm-Message-State: AOAM533hi4Dlqh3EqcF7WOa+UvLWqUD8RgDNtKHBeA95qI2RBs5qEJzW 5LCPXHY6Blqdb3W++iPG9Yj526jLu9+9v/RBzeDYiQ== X-Google-Smtp-Source: ABdhPJwfSG3qwXs5bQuYdyE/huOMWjC47v92jpM7+emhAp9p30J97HIKs9kH+py53E7/B61E/8mvc1zLY3xgno9e/3s= X-Received: by 2002:a05:6830:16c4:: with SMTP id l4mr3283124otr.161.1589753534361; Sun, 17 May 2020 15:12:14 -0700 (PDT) MIME-Version: 1.0 References: <20200503165802.6540ad48@tarpaulin.shahaf.local2> <20200504131830.3572e317@tarpaulin.shahaf.local2> <20200505164934.3f6b7f42@tarpaulin.shahaf.local2> <20200507204007.7487332d@tarpaulin.shahaf.local2> <20200516204840.3a302225@tarpaulin.shahaf.local2> In-Reply-To: From: Bart Schaefer Date: Sun, 17 May 2020 15:12:03 -0700 Message-ID: Subject: Re: Help Request/Bug Report: comparguments causes _arguments to fail in certain cases To: Dan Arad Cc: Zsh Users Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Reordering discussion slightly ... On Sat, May 16, 2020 at 1:49 PM Daniel Shahaf wrot= e: > > Dan Arad wrote on Fri, 15 May 2020 17:39 +0300: > > The thing is, that now I'm faced with a different problem: > > When the command line is `python ps.py`, the actual completions are joi= ned > > by the list of files in the current directory. > > > > This appears to be a byproduct of going through the `_python` > > auto-completion script. > > > > Also, might this be a bug in the `_python` completion script? > > I don't see how. It's normal for completion to offer files as a > fallback for unknown commands, as in =C2=ABnosuchcommand =C2=BB. This isn't happening because of an unknown command, it's because the historic behavior of _normal is to return all files when none match the specific completer. I've mentioned this before; the thought at the time was that it would be even more confusing for completion to beep failure at you when there was at least one file in the directory. > > I was wondering if there is a way to remove existing completion matches > > before adding my own to make sure I provide only correct matches. > > I don't think there's a way to remove already-added matches. Completers that want to do this sort of thing typically do a hack: Wrap the "compadd" builtin with a function that uses "builtin compadd -O array" (or "-A array") to capture the completions without actually adding them, and then later remove the wrapper and make the real compadd call. However, I don't think you need or want to do that here. On Sun, May 17, 2020 at 12:26 PM Dan Arad wrote: > > The `_python` script is called before my script (assuming your command li= ne > starts with python), and I actually use it to my advantage, since it > updates `words` so that the script name is always the first element, maki= ng > my job easier. I think you're mis-stating this. The _python function (I'm going to be pedantic that a function is not the same as a script) is called AROUND your _python_script function. You have this call sequence correct: > Given the command line `python ./ps.py`: > `_python_script_words_backup`: Backs up `words` and returns to `_complete= ` > `_complete`: Calls `_normal` which calls `_dispatch` which calls `_pytho= n` > `_python`: Adds its own arguments, shifts `words` and calls `_normal` whi= ch > calls `_dispatch` which calls `_python_script` However, nothing will have been "compadd"ed by _python at the point at which it calls _normal. Anything that gets added is being added as consequence of calling _normal, not as a consequence of calling _python. > [Daniel Shahaf again in a later message]: > > you should look for a way to prevent _python from > > running when your function has added matches. For starters, does your > > function return 0 when it has added matches? > > So regarding what you wrote here, I add my matches after `_python` has ru= n No, you add them while _python is still running, not after. > and not before. I also use `_compskip=3Dall` That doesn't actually do very much once you are beyond -first-. It aborts the current level of _dispatch but doesn't prevent the outer _default that called _python from continuing on into -default-, which I think you'll find to be the place your extra matches are coming from. > and always return 0, but since > it is after `_python` has already run, it doesn't solve this particular > problem. What you would need here is for _python to set _compskip, because it's local to each level of _dispatch. > > Additionally, overwriting -first- is > > not a composable approach: users who already overwrite -first- won't be > > able to install your completion function alongside their existing > > configuration. > > Would you propose using a different `compdef` specification for > `_python_script_words_backup`? No, I'd suggest using a different compdef for "python" itself. E.g.: _python_or_script() { _python_script_words_backup _python "$@" && _compskip=3Dall } compdef _python_or_script python (and remove your -first- compdef).