* [BUG?] Unexpected behaviour with `compdef -p` @ 2018-10-03 14:56 ` dana 2018-10-03 17:02 ` Peter Stephenson 0 siblings, 1 reply; 3+ messages in thread From: dana @ 2018-10-03 14:56 UTC (permalink / raw) To: Zsh hackers list 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 ^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: [BUG?] Unexpected behaviour with `compdef -p` 2018-10-03 14:56 ` [BUG?] Unexpected behaviour with `compdef -p` dana @ 2018-10-03 17:02 ` Peter Stephenson 2018-10-04 18:44 ` dana 0 siblings, 1 reply; 3+ messages in thread From: Peter Stephenson @ 2018-10-03 17:02 UTC (permalink / raw) To: zsh-workers 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 ^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: [BUG?] Unexpected behaviour with `compdef -p` 2018-10-03 17:02 ` Peter Stephenson @ 2018-10-04 18:44 ` dana 0 siblings, 0 replies; 3+ messages in thread From: dana @ 2018-10-04 18:44 UTC (permalink / raw) To: Peter Stephenson; +Cc: zsh-workers 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 ^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2018-10-04 18:44 UTC | newest] Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- [not found] <CGME20181003145704epcas2p11789ab46bc01269295dacdb9cbe9f9d6@epcas2p1.samsung.com> 2018-10-03 14:56 ` [BUG?] Unexpected behaviour with `compdef -p` dana 2018-10-03 17:02 ` Peter Stephenson 2018-10-04 18:44 ` dana
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).