[BUG?] Unexpected behaviour with `compdef -p`

[BUG?] Unexpected behaviour with `compdef -p`

[dana]

I was trying to use `compdef -p` to avoid having to list out a large number of
commands i want to complete that all have the same prefix, and i found that it
doesn't really work the way i expected — it destroys the completion output.

Example (with completion loaded obv, and i have menu selection on in my case):

  % cat _xyz
  _arguments -s -S : {-h,--help}'[display help information]'
  % fpath=( $PWD $fpath )
  % autoload -Uz _xyz
  % compdef _xyz -p 'xyz*'
  % xyzabc -<TAB>
  completing option:
  --help
  -h
    display help information
  --help
  -h
    display help information
  --help
  -h
    display help information
  <... and so on; the output is essentially garbage>

When i use -P instead of -p, the output is as expected.

Mikael had the following to say when i brought it up on IRC:

  < Mikachu> i guess it ends up calling the completer two times
  < Mikachu> -p is tried "before other completions"
  < Mikachu> okdana: if i do the compdef _xyz -P xyz\* then
  < Mikachu> xyz <tab> will show just -h and --help
  < Mikachu> if i do -p instead, then xyz <tab> shows -h and --help correctly
             but also completes files
  < Mikachu> if i do xyz -<tab> then it shows the bogus output
  < Mikachu> so yeah, with -p you call your completer, then the default
             completer list is tried in some weird way, and then the completer
             gets called again by the normal path
  < Mikachu> i don't know if any of that is intended
  < Mikachu> (i also made sure to use compdef -d -p xyz\* etc between each test)

I am not that familiar with the part of the completion system that deals with
this. Is the above in fact the intended behaviour? (If it is, what scenario
would one use -p in where it wouldn't cause these problems?)

dana

Re: [BUG?] Unexpected behaviour with `compdef -p`

[Peter Stephenson]

On Wed, 2018-10-03 at 09:56 -0500, dana wrote:
> I was trying to use `compdef -p` to avoid having to list out a large
> number of commands i want to complete that all have the same prefix,
> and i found that it doesn't really work the way i expected — it
> destroys the completion output.
> 
> I am not that familiar with the part of the completion system that
> deals with this. Is the above in fact the intended behaviour? (If it
> is, what scenario would one use -p in where it wouldn't cause these
> problems?)

The code's not *that* complicated, this time --- look in

Completion/Base/Core/_dispatch

The loop with _patcomps is handling the compdef -p.  Then the normal
name look-up happens.  This looks like it could be trashing your input.
With a judicious "if" around that bit, and probably also setting name
and comp in the loop above, you ought to be able to get it to work, I
think.

pws

Re: [BUG?] Unexpected behaviour with `compdef -p`

[dana]

On 3 Oct 2018, at 12:02, Peter Stephenson <p.stephenson@samsung.com> wrote:
>The code's not *that* complicated, this time

Yeah, i guess it's not so bad.

Looking at it more, and also looking at how the very few existing functions that
make use of `compdef -p` actually do it, it seems like maybe it's just the way
it's supposed to work?

The thing that determines whether it moves on to normal completion is
$_compskip, which can be set to 'all' to make it stop after it finds a matching
pattern. This is what _init_d and _zftp do, and both of those just so happen to
have been written by the same person that added pattern-based completion (Sven).

The manual does kind of hint at this, but it's not very clear. To make matters
worse, the documentation for compdef is spread across one section for the
#compdef tag and then another section for the actual compdef function. I feel
like it should be consolidated as much as possible to one or the other, but it'd
be a pretty big change that i'm a little nervous about making unilaterally.

In the mean time, here's some clarification.

dana


diff --git a/Doc/Zsh/compsys.yo b/Doc/Zsh/compsys.yo
index 65f596752..a5a9e5b5d 100644
--- a/Doc/Zsh/compsys.yo
+++ b/Doc/Zsh/compsys.yo
@@ -489,7 +489,11 @@ The parameter tt($_compskip) may be set by any function defined for a
 pattern context.  If it is set to a value containing the substring
 `tt(patterns)' none of the pattern-functions will be called; if it is
 set to a value containing the substring `tt(all)', no other function
-will be called.
+will be called.  Setting tt($_compskip) in this manner is of particular
+utility when using the tt(-p) option, as otherwise the dispatcher will
+move on to additional functions (likely the default one) after calling
+the pattern-context one, which can mangle the display of completion
+possibilities if not handled properly.
 
 The form with tt(-k) defines a widget with the same name as the var(function)
 that will be called for each of the var(key-sequence)s; this is like the