Zsh Mailing List Archive
Messages sorted by:
Re: Help Request/Bug Report: comparguments causes _arguments to fail in certain cases
- X-seq: zsh-users 24849
- From: Bart Schaefer <schaefer@xxxxxxxxxxxxxxxx>
- To: Dan Arad <dan1994@xxxxxxxxx>
- Subject: Re: Help Request/Bug Report: comparguments causes _arguments to fail in certain cases
- Date: Sun, 17 May 2020 15:12:03 -0700
- Cc: Zsh Users <zsh-users@xxxxxxx>
- In-reply-to: <CAPPzoJBWJ8-yf1f-3ibP2BrJLOgy5k0=YiUf-B=763EKLHFViw@mail.gmail.com>
- List-help: <mailto:email@example.com>
- List-id: Zsh Users List <zsh-users.zsh.org>
- List-post: <mailto:firstname.lastname@example.org>
- List-unsubscribe: <mailto:email@example.com>
- Mailing-list: contact zsh-users-help@xxxxxxx; run by ezmlm
- References: <CAPPzoJDB3jB7pHUfE7UjY09OHk+r_pgLeYxuaoXhMFGHf-3UCQ@mail.gmail.com> <firstname.lastname@example.org> <CAPPzoJDyK35bSMTyYKovEbRZNhDpKs1aeY2ZRjzBTxgdgCuGww@mail.gmail.com> <email@example.com> <CAPPzoJC6MYg8CEqsmLRPvPRYPLYP+dJxA4BCR0Cue6xTdZ9Q9g@mail.gmail.com> <firstname.lastname@example.org> <CAPPzoJDeGo_gzn9DFCv1Zd=m6bDO34AK1K-KSmxwu-9mQHcKtg@mail.gmail.com> <email@example.com> <CAPPzoJD-DqObF630EAF63Ptn-=ftiEmnywSb-w6KmfhBQ7DCkw@mail.gmail.com> <firstname.lastname@example.org> <CAPPzoJDL_vpLHe5iNgiNP6desAt_SmwEHLurY0W-JN4YrwqvbA@mail.gmail.com> <CAPPzoJBWJ8-yf1f-3ibP2BrJLOgy5k0=YiUf-B=763EKLHFViw@mail.gmail.com>
Reordering discussion slightly ...
On Sat, May 16, 2020 at 1:49 PM Daniel Shahaf <d.s@xxxxxxxxxxxxxxxxxx> wrote:
> 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 joined
> > 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 «nosuchcommand <TAB>».
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
On Sun, May 17, 2020 at 12:26 PM Dan Arad <dan1994@xxxxxxxxx> wrote:
> The `_python` script is called before my script (assuming your command line
> 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, making
> 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
> 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 `_python`
> `_python`: Adds its own arguments, shifts `words` and calls `_normal` which
> 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
> [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 run
No, you add them while _python is still running, not after.
> 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
> and always return 0, but since
> it is after `_python` has already run, it doesn't solve this particular
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
No, I'd suggest using a different compdef for "python" itself. E.g.:
_python "$@" && _compskip=all
compdef _python_or_script python
(and remove your -first- compdef).
Messages sorted by: