zsh-users
 help / color / mirror / code / Atom feed
From: Dan Arad <dan1994@gmail.com>
To: Daniel Shahaf <d.s@daniel.shahaf.name>, zsh-users@zsh.org
Subject: Fwd: Help Request/Bug Report: comparguments causes _arguments to fail in certain cases
Date: Sun, 17 May 2020 22:25:02 +0300	[thread overview]
Message-ID: <CAPPzoJBWJ8-yf1f-3ibP2BrJLOgy5k0=YiUf-B=763EKLHFViw@mail.gmail.com> (raw)
In-Reply-To: <CAPPzoJDL_vpLHe5iNgiNP6desAt_SmwEHLurY0W-JN4YrwqvbA@mail.gmail.com>

[-- Attachment #1: Type: text/plain, Size: 5602 bytes --]

---------- Forwarded message ---------
From: Dan Arad <dan1994@gmail.com>
Date: Sun, May 17, 2020, 11:05
Subject: Re: Help Request/Bug Report: comparguments causes _arguments to
fail in certain cases
To: Daniel Shahaf <d.s@daniel.shahaf.name>


I think you're mixing things up, so I'll try to clarify:

The only thing I do in the `-first-` script is to backup `words` in another
variable. Otherwise it doesn't affect the completion flow (and my other
bug) at all.
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.

To make things easier to understand, my main script is called
`_python_script`, and the `-first-` script is called
`_python_script_words_backup`.

The two scenarios (starting from the first thing called by `_complete`):

Given the command line `./ps.py`:
`_python_script_words_backup`: Backs up `words` and returns to `_complete`
`_complete`: Calls `_normal` which calls `_dispatch` which  calls
`_python_script`
`_python_script`: Uses the first item in the `words` variable to determine
the what is the script

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`
`_python_script`: Uses the updated `words` the same as in the first
scenario to determine which script is run, and adds the actual completion

How would that help if it existed?  I assume -first- runs before
> _python, not after, so 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
and not before. I also use `_compskip=all` and always return 0, but since
it is after `_python` has already run, it doesn't solve this particular
problem.

In short, if I want to bypass `_python`, I would probably have to change my
`compdef` definition from `-P *.py` to `-P *`, but then I'll have to parse
everything myself again, losing the great advantage `_python` has given me.

I also thought about using the `_ignore` directive, but I'm not exactly
sure how to use it, or if it can even be used for this use case.

And about this:

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`? Using something like `-p *` is not right for
this case, as it will be called multiple times (including after `_python`
has run) and will overwrite the backup.

Cheers,
Dan

On Sat, May 16, 2020 at 11:48 PM Daniel Shahaf <d.s@daniel.shahaf.name>
wrote:

> Dan Arad wrote on Fri, 15 May 2020 17:39 +0300:
> > I got it working using the hook method: I added another script with
> > `#compdef -first-` that saves the words array.
> >
>
> Nice :)
>
> > The thing is, that now I'm faced with a different problem:
> > When the command line is `./ps.py`, completions are generated correctly.
> > 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.
> >
> > 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.
>
> How would that help if it existed?  I assume -first- runs before
> _python, not after, so 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?
>
> Or you could arrange for «python ps.py» to call your script without
> a -first- completion function.  That should prevent _python from
> falling back to completing files.  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.
>
> > 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>».
>
> I don't recall offhand how to disable or modify the fallback behaviour.
>
> > Thanks for all the help,
> > Dan
>
> You're welcome.
>
> Cheers,
>
> Daniel
>
> P.S. While I wrote the above I ran into this:
>
> diff --git a/Doc/Zsh/compsys.yo b/Doc/Zsh/compsys.yo
> index 98ab46d8a..8d2813c5a 100644
> --- a/Doc/Zsh/compsys.yo
> +++ b/Doc/Zsh/compsys.yo
> @@ -1685,6 +1685,9 @@ example(zstyle ':completion:*' group-name '')
>
>  All matches for which no group name is defined will be put in a group
>  named tt(-default-).
> +
> +To display the group name in the output, see the tt(format) style (q.v.)
> +under the tt(descriptions) tag.
>  )
>  kindex(group-order, completion style)
>  item(tt(group-order))(
>


-- 
Dan Arad
dan1994@gmail.com

  parent reply	other threads:[~2020-05-17 19:26 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <CAPPzoJDB3jB7pHUfE7UjY09OHk+r_pgLeYxuaoXhMFGHf-3UCQ@mail.gmail.com>
     [not found] ` <20200503165802.6540ad48@tarpaulin.shahaf.local2>
     [not found]   ` <CAPPzoJDyK35bSMTyYKovEbRZNhDpKs1aeY2ZRjzBTxgdgCuGww@mail.gmail.com>
     [not found]     ` <20200504131830.3572e317@tarpaulin.shahaf.local2>
2020-05-04 17:13       ` Dan Arad
2020-05-05 16:49         ` Daniel Shahaf
2020-05-07 19:24           ` Dan Arad
2020-05-07 20:40             ` Daniel Shahaf
2020-05-15 14:39               ` Dan Arad
2020-05-16 20:48                 ` Daniel Shahaf
     [not found]                   ` <CAPPzoJDL_vpLHe5iNgiNP6desAt_SmwEHLurY0W-JN4YrwqvbA@mail.gmail.com>
2020-05-17 19:25                     ` Dan Arad [this message]
2020-05-17 22:12                       ` Bart Schaefer
2020-05-17 22:14                         ` Bart Schaefer
2020-05-18  6:20                           ` Dan Arad

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='CAPPzoJBWJ8-yf1f-3ibP2BrJLOgy5k0=YiUf-B=763EKLHFViw@mail.gmail.com' \
    --to=dan1994@gmail.com \
    --cc=d.s@daniel.shahaf.name \
    --cc=zsh-users@zsh.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.vuxu.org/mirror/zsh/

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).