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=DKIM_ADSP_CUSTOM_MED, FREEMAIL_FROM,MAILING_LIST_MULTI,RCVD_IN_DNSWL_NONE autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 11681 invoked from network); 18 May 2020 06:21:47 -0000 Received: from ns1.primenet.com.au (HELO primenet.com.au) (203.24.36.2) by inbox.vuxu.org with ESMTPUTF8; 18 May 2020 06:21:47 -0000 Received: (qmail 2032 invoked by alias); 18 May 2020 06:21:41 -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: 24852 Received: (qmail 11213 invoked by uid 1010); 18 May 2020 06:21:41 -0000 X-Qmail-Scanner-Diagnostics: from mail-il1-f178.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.166.178):SA:0(-1.7/5.0):. Processed in 2.08282 secs); 18 May 2020 06:21:41 -0000 X-Envelope-From: dan1994@gmail.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.166.178 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; bh=4p+SvcA7h92C7vhr5pBb6erzFq4TxMtDMwDLJ695UeY=; b=LE0tH0kg3Qrqtio6rMp93jHjjnmujbUVe3bxmAwgPYhjJwubdpvsuXLayyMdaa3yOp LJNh6XqfM3tyzuswvR3ReuslgC6g2qwAh6cNOCr4IzlSM5zbUbIffPY5xbtx1L2UMltQ fuJHpgRNiD6uqsHx+OL4f6jF1lEgntrKW3ttU+H8GN6bhLctBaM8vxZIrQTEW9zWHLRB 1UFVoM+N4vuDMKZeGZV6Rs4jv7yE2sDkMrboFjokB4Owz8u2iTIqWOSNTf50H2eN240W zYmoYrrFxj46VDkE6pnDPoztYyFYufiZRO0POpjtymcDV5tvxsEuQdfSFPy+tj/+qRqy Slcg== X-Gm-Message-State: AOAM533bzfztLEcXksEKPaITqLiX+4FC3LAmNku0auDqcNbLISMfl9nt WOzksquLmzvuTt6SIg+NLNGlGp+qvSO9xEe3Vspsur+x0eU= X-Google-Smtp-Source: ABdhPJyVocW5vBsLGKiojWXHNaN/sDXZKoFBos/dDMBHz7kPY3CIYskNY8MzH47RZxiyKWmm3NYCp9hV1kLDXyAYKf8= X-Received: by 2002:a92:bf06:: with SMTP id z6mr13943458ilh.191.1589782865737; Sun, 17 May 2020 23:21:05 -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: Dan Arad Date: Mon, 18 May 2020 09:20:49 +0300 Message-ID: Subject: Re: Help Request/Bug Report: comparguments causes _arguments to fail in certain cases To: Bart Schaefer Cc: Zsh Users Content-Type: multipart/alternative; boundary="000000000000fb7ef505a5e62ae0" --000000000000fb7ef505a5e62ae0 Content-Type: text/plain; charset="UTF-8" Thanks for the great clarifications! I'll try to stick to the correct technical terms. 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. ... 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. I suspected as much, but I'm new to zsh and completion, so I had some hard time following the debug logs and figuring this out. _python_or_script() { > _python_script_words_backup > _python "$@" && _compskip=all > } > compdef _python_or_script python This works like a charm! The only thing I did different is to use the `#compdef -p` form at the beginning of the file so I could give the same pattern as that of the `_python` function. > and not before. I also use `_compskip=all` > > 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. This `_compskip` prevents the inner `_dispatch` from calling the `_python_script` function more than once. An example I've seen, is with the command line `python .vscode/ps.py` (I use the .vscode directory as a place for temporary files as it is git ignored). In this case, without `_compskip=all`, the inner `_dispatch` calls `_python_script` once with `service=.vscode/ps.py` and once with `service=ps.py`. In my case this doubles the time to produce completions which may be critical depending on the way the user has written his script. To conclude, I would really like to thank everybody who took part in this discussion. This is my first open source project, and I was really hoping to provide a good user experience. It was a great experience for me to have such a productive conversation, and I really appreciate the time you've put into providing detailed answers in a welcoming manner. Have a great day! Dan On Mon, May 18, 2020 at 1:14 AM Bart Schaefer wrote: > On Sun, May 17, 2020 at 3:12 PM Bart Schaefer > wrote: > > > > aborts the current level of _dispatch but doesn't prevent the outer > > _default that called _python from continuing on into -default-, which > > Typo, that should say "... the outer _dispatch that ..." > -- Dan Arad dan1994@gmail.com --000000000000fb7ef505a5e62ae0--