Completion

Completion

[Etienne Chové]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

I'm trying to make a completion for a script, the command look like :
whos nom=nom1&prenom=prenom2

I wrote a completion funtion like :
<begin>
#compdef whos

_recherche () {
  if compset -S '' -P '(|*&)'; then
    compadd -S '=' - nom prenom
  elif compset -P '*A'; then
    compadd - nom1 nom2
  elif compset -P '*prenom='; then
    compadd - prenom1 prenom2
  fi
}

_arguments \
  '*:expression:_recherche'
</end>

But it won't complete prenom because it match with the first condition. Is
th'ere a easy colution to have completion ?

Thanks.

- --
Etienne
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2 (GNU/Linux)

iD8DBQFD+bv1vsnSxJjnYzIRAruxAJ9O4jfI/P17yeDEY2HNHFq8JrvLdACeKfbl
rXNChIVCM9RlyPbWdudv6AA=
=ow3l
-----END PGP SIGNATURE-----

Re: Completion

[Clint Adams]

> But it won't complete prenom because it match with the first condition. Is
> th'ere a easy colution to have completion ?

Is this closer to what you want?

#compdef whos

_recherche () {
        if compset -P '*prenom='; then
                compadd - prenom1 prenom2
        elif compset -P '(|*&)'; then
                compadd -S '=' - nom prenom
        elif compset -P '*A'; then
                compadd - nom1 nom2
        fi
}

_arguments \
   '*:expression:_recherche'

Re: Completion

[Etienne Chové]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Clint Adams a écrit :
>>But it won't complete prenom because it match with the first condition. Is
>>th'ere a easy colution to have completion ?

Yes, thanks

- --
Bilou
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2 (GNU/Linux)

iD8DBQFD+hzRvsnSxJjnYzIRAlyOAJ96Z3DWHFR2weTV++EGirht7VFwBACglnz2
4acbSA/N39VbOX+Oo0prdCA=
=Bvrn
-----END PGP SIGNATURE-----

Re: completion

[Bart Schaefer]

On Jan 13,  5:03pm, Vincent Lefevre wrote:
}
} So, for readability and to avoid any ambiguity, I suggest that the
} documentation be updated to use only the form with all the colons,
} except when "*" is only used at the end.

We accept patches at zsh-workers@zsh.org, 24 hours a day, 7 days a week.

-- 
Barton E. Schaefer

Re: completion

[Vincent Lefevre]

On 2015-01-12 08:43:08 -0800, Bart Schaefer wrote:
> On Jan 12, 10:09am, Vincent Lefevre wrote:
> }
> } Why hasn't this been done for the man page?
> 
> Because no one considered that one might be using the _foo completer
> for a command whose name is "complete", because there is no such
> command?
> 
> Documentation people make mistakes too ... and none of us is really
> a documentation people.

So, for readability and to avoid any ambiguity, I suggest that the
documentation be updated to use only the form with all the colons,
except when "*" is only used at the end.

-- 
Vincent Lefèvre <vincent@vinc17.net> - Web: <https://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Re: completion

[Bart Schaefer]

On Jan 12, 10:09am, Vincent Lefevre wrote:
}
} Why hasn't this been done for the man page?

Because no one considered that one might be using the _foo completer
for a command whose name is "complete", because there is no such
command?

Documentation people make mistakes too ... and none of us is really
a documentation people.

Re: completion

[Vincent Lefevre]

On 2015-01-09 18:12:41 -0800, Bart Schaefer wrote:
> On Jan 8,  1:36pm, Vincent Lefevre wrote:
> }
> } I don't understand. I suppose that the real intent of
> } 
> }     zstyle ':completion:*:complete:*' matcher-list [...]
> } 
> } was to match the completer "complete", i.e. like
> } 
> }     zstyle ':completion:*:complete:*:*:*' matcher-list [...]
> } 
> } But what if the context is ":completion::foo:complete::" in some
> } completion, i.e. with the completer "foo" and the command "complete"?
> 
> First of all, the completer "_foo" would have had to have been added
> to the "completer" style (the default value of this style is _complete
> and _ignored), and second, the _foo function would have to contain a
> zstyle command that looks up the value of the matcher-list style.  If
> either of those conditions does not hold, the context will never be
> ":completion::foo:complete::" and the question is not relevant.

There is something similar in the zshcompsys(1) man page:

    zstyle ':completion:*' completer _complete _correct _complete:foo
    zstyle ':completion:*:complete:*' matcher-list \
        '' 'm:{a-zA-Z}={A-Za-z}'
    zstyle ':completion:*:foo:*' matcher-list \
        'm:{a-zA-Z}={A-Za-z} r:|[-_./]=* r:|=*'

> The assumption, therefore, is that if the user has deliberately added
> _foo to the completer style, then he is also aware that _foo may want
> to look up match-list, and therefore he will have used the form with
> more colons and/or fewer asterisks when defining the matcher-list for
> each of the two completers that want a matcher-list.

Why hasn't this been done for the man page?

-- 
Vincent Lefèvre <vincent@vinc17.net> - Web: <https://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Re: completion

[Bart Schaefer]

On Jan 8,  9:12am, Ray Andrews wrote:
}
} Ah! So I find myself reaching for a better word. 'ambiguity' =
} uncertainty or confusion. What we have here, then, is not confusion,
} but rather a carefully expanded space of possibilities, or freedoms.

Yes, that's basically on the right track.

Here's some additional text for the compsys documentation that might
help.  Also moved a couple of things around to introduce them sooner.
Still could probably use work.


diff --git a/Doc/Zsh/compsys.yo b/Doc/Zsh/compsys.yo
index 920b590..2cdc57a 100644
--- a/Doc/Zsh/compsys.yo
+++ b/Doc/Zsh/compsys.yo
@@ -533,21 +533,41 @@ generated.
 subsect(Overview)
 
 When completion is attempted somewhere on the command line the
-completion system first works out the context.  This takes account of a
+completion system begins building the context.  The context represents
+everything that the shell knows about the meaning of the command line
+and the significance of the cursor position.  This takes account of a
 number of things including the command word (such as `tt(grep)' or
 `tt(zsh)') and options to which the current word may be an argument
 (such as the `tt(-o)' option to tt(zsh) which takes a shell option as an
 argument).
 
-This context information is condensed into a string consisting of
-multiple fields separated by colons, referred to simply as `the context'
-in the remainder of the documentation.  This is used to look up
-em(styles), context-sensitive options that can be used to configure the
-completion system.  The context used for lookup may vary during the same
-call to the completion system.
+The context starts out very generic ("we are beginning a completion")
+and becomes more specific as more is learned ("the current word is in a
+position that is usually a command name" or "the current word might be a
+variable name" and so on).  Therefore the context will vary during the
+same call to the completion system.
+
+This context information is condensed into a string consisting of multiple
+fields separated by colons, referred to simply as `the context' in the
+remainder of the documentation.  Note that a user of the completion system
+rarely needs to compose a context string, unless for example a new
+function is being written to perform completion for a new command.  What a
+user may need to do is compose a em(style) pattern, which is matched
+against a context when needed to look up context-sensitive options that
+configure the completion system.
+
+The next few paragraphs explain how a context is composed within the
+completion function suite.  Following that is discussion of how em(styles)
+are defined.  Styles determine such things as how the matches are
+generated, similarly to shell options but with much more control.  They
+are defined with the tt(zstyle) builtin command (\
+ifzman(see zmanref(zshmodules))\
+ifnzman(noderef(The zsh/zutil Module))).
 
 The context string always consists of a fixed set of fields, separated
-by colons and with a leading colon before the first, in the form
+by colons and with a leading colon before the first.  Fields which are
+not yet known are left empty, but the surrounding colons appear anyway.
+The fields are always in the order
 tt(:completion:)var(function)tt(:)var(completer)tt(:)var(command)tt(:)var(argument)tt(:)tt(tag).  These have the following meaning:
 
 startitemize()
@@ -628,17 +648,13 @@ described in
 ifzman(the section `Bindable Commands' below)\
 ifnzman(noderef(Bindable Commands)).
 
-Styles determine such things as how the matches are generated, similarly
-to shell options but with much more control.  They can have any number
-of strings as their value.  They are defined with the tt(zstyle) builtin
-command (\
-ifzman(see zmanref(zshmodules))\
-ifnzman(noderef(The zsh/zutil Module))).
-
 When looking up styles the completion system uses full context names,
-including the tag.  Looking up the value of a style therefore consists
-of two things:  the context, which may be matched as a pattern, and the
-name of the style itself, which must be given exactly.
+including the tag.  Looking up the value of a style therefore consists of
+two things: the context, which is matched to the most specific (best
+fitting) style pattern, and the name of the style itself, which must be
+matched exactly.  The following examples demonstrate that style patterns
+may be loosely defined for styles that apply broadly, or as tightly
+defined as desired for styles that apply in narrower circumstances.
 
 For example, many completion functions can generate matches in a
 simple and a verbose form and use the tt(verbose) style to decide

Re: completion

[Bart Schaefer]

On Jan 8,  1:36pm, Vincent Lefevre wrote:
}
} I don't understand. I suppose that the real intent of
} 
}     zstyle ':completion:*:complete:*' matcher-list [...]
} 
} was to match the completer "complete", i.e. like
} 
}     zstyle ':completion:*:complete:*:*:*' matcher-list [...]
} 
} But what if the context is ":completion::foo:complete::" in some
} completion, i.e. with the completer "foo" and the command "complete"?

First of all, the completer "_foo" would have had to have been added
to the "completer" style (the default value of this style is _complete
and _ignored), and second, the _foo function would have to contain a
zstyle command that looks up the value of the matcher-list style.  If
either of those conditions does not hold, the context will never be
":completion::foo:complete::" and the question is not relevant.

The assumption, therefore, is that if the user has deliberately added
_foo to the completer style, then he is also aware that _foo may want
to look up match-list, and therefore he will have used the form with
more colons and/or fewer asterisks when defining the matcher-list for
each of the two completers that want a matcher-list.

} It would match, wouldn't it? But the intent was to match only the
} completer "complete", not "foo"!

The zstyle command can't psychically predict the user's intent.  It's
not up to zstyle to make it impossible for the user to mistakenly use
a pattern that's not specific enough.  It's also not up to zstyle to
force the user to make patterns more specific than necessary.  The
format is carefully documented and the user can be as paranoid as he
wishes to be in limiting the contexts that match.

Re: completion

[Vincent Lefevre]

On 2015-01-08 09:12:24 -0800, Ray Andrews wrote:
> Ah!  So I find myself reaching for a better word. 'ambiguity' = uncertainty
> or confusion. What we have here, then, is not confusion, but rather a
> carefully expanded space of possibilities, or freedoms.

Yes, perhaps I should have said that the pattern potentially matches
too much, i.e. it can match contexts that shouldn't have been matched.

-- 
Vincent Lefèvre <vincent@vinc17.net> - Web: <https://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Re: completion

[Ray Andrews]

On 01/07/2015 09:26 PM, Bart Schaefer wrote:
> On Wed, Jan 7, 2015 at 4:43 PM, Vincent Lefevre <vincent@vinc17.net> wrote:
>> But the ambiguity shouldn't be intentional.
> Nevertheless, it is.
...

If * matches everything, then this could mean [any of]

   :completion:[any function]:complete:[any cmd]:[any arg]:[any tag]
   :completion:[any function]:[any completer]:complete:[any arg]:[any tag]
   :completion:[any function]:[any completer]:[any cmd]:complete:[any tag]

> You're correct, it could.  But "matcher-list" also has to match, and
> THAT only happens in one of those three cases, so there's no need to
> constrain the pattern any further (unless you WANT to; refer to my
> car-cover analogy).
Ah!  So I find myself reaching for a better word. 'ambiguity' = 
uncertainty or confusion. What we have here, then, is not confusion, but 
rather a carefully
expanded space of possibilities, or freedoms.

    $ ls zsh* ... the asterisk is not ambiguous, we know *exactly* what 
is means.
It expands the matching space, but that is not an ambiguity because we know
exactly what the rules are.  If our zstyle asterisks do something 
analogous, then they are not an ambiguity.  Right? Wrong?

Re: completion

[Ray Andrews]

On 01/08/2015 12:31 AM, Bart Schaefer wrote:
> On Jan 7,  3:00pm, Ray Andrews wrote:
> }
> } To put it in English, what I'm reaching for (I think), sounds something
> } like this:
> }
> } If [something-on-command-line] matches [this-pattern] (a filter), then
> } expand that pattern using [this-particular-set-of-rules], and then
> } search (go find) in [this-particular-group-of-objects] for
> } [this-particular-glob-pattern] and put that on my command line.
>
> Incidentally, no, it's not like that at all.  In fact its so far from
> that, that I can't even reword the above to give a better sense of it.
> Completion involves several layers of loops-within-loops, it can't be
> described in a single if-then sentence.
Well that's hardly a surprise to hear, because the square peg of what
my preconception is/was definitely does not go through the round hole
of what happens.  You know, I was going to give completion a rest and
try again in a year, but since Vincent brought the subject up again, and
there's new food to digest, I'd better reread the docs again in the light
of this new explanation and maybe I will get it. At the moment, my mind
just melts down at the 'asterisk' part, I just can't grok ambiguously
omitted field separators, it ain't humanly decent.
>
> If you ignore a lot of the looping parts and the listing of ambiguous
> matches, then it's sort of like:
>
> Choose a completer and pass it some information about the command line,
> from which it will construct a context which summarizes the meaning of
> the command line in about six words.  For each/any configuration option
> that may be useful, use the context to find the best definition among
> the set of zstyle patterns the user has defined.  Some of those options
> (called styles) should explain where to look for [this-particular-group-
> of-strings], otherwise use a fallback to find them.  Compare whatever
> strings you end up with to the word to the left of or under the cursor
> and put the longest unambiguous common substring that matches on the
> command line, assuming the other styles said that's what you should do.
> If there aren't any matches at all, try again with the next completer
> until something is found or there are no more completers.
I'm lost after 'choose a completer' ;-) ... what does that mean? I expect
that zsh *provides* me with the completer ....

Nevermind! I've got to reread.  For now, I'm interested to see how you
respond to Vincent, he already mostly understands this.  I don't
understand enough to be even worth talking to.

Re: completion

[Vincent Lefevre]

On 2015-01-07 21:26:44 -0800, Bart Schaefer wrote:
> On Wed, Jan 7, 2015 at 4:43 PM, Vincent Lefevre <vincent@vinc17.net> wrote:
> >       zstyle ':completion:*:complete:*' matcher-list [...]
> >
> > If * matches everything, then this could mean [any of]
> >
> >   :completion:[any function]:complete:[any cmd]:[any arg]:[any tag]
> >   :completion:[any function]:[any completer]:complete:[any arg]:[any tag]
> >   :completion:[any function]:[any completer]:[any cmd]:complete:[any tag]
> 
> You're correct, it could.  But "matcher-list" also has to match, and
> THAT only happens in one of those three cases, so there's no need to
> constrain the pattern any further (unless you WANT to; refer to my
> car-cover analogy).

I don't understand. I suppose that the real intent of

    zstyle ':completion:*:complete:*' matcher-list [...]

was to match the completer "complete", i.e. like

    zstyle ':completion:*:complete:*:*:*' matcher-list [...]

But what if the context is ":completion::foo:complete::" in some
completion, i.e. with the completer "foo" and the command "complete"?
It would match, wouldn't it? But the intent was to match only the
completer "complete", not "foo"!

-- 
Vincent Lefèvre <vincent@vinc17.net> - Web: <https://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Re: completion

[Bart Schaefer]

On Jan 7,  3:00pm, Ray Andrews wrote:
}
} To put it in English, what I'm reaching for (I think), sounds something 
} like this:
} 
} If [something-on-command-line] matches [this-pattern] (a filter), then 
} expand that pattern using [this-particular-set-of-rules], and then 
} search (go find) in [this-particular-group-of-objects] for 
} [this-particular-glob-pattern] and put that on my command line.

Incidentally, no, it's not like that at all.  In fact its so far from
that, that I can't even reword the above to give a better sense of it.
Completion involves several layers of loops-within-loops, it can't be
described in a single if-then sentence.

If you ignore a lot of the looping parts and the listing of ambiguous
matches, then it's sort of like:

Choose a completer and pass it some information about the command line,
from which it will construct a context which summarizes the meaning of
the command line in about six words.  For each/any configuration option
that may be useful, use the context to find the best definition among
the set of zstyle patterns the user has defined.  Some of those options
(called styles) should explain where to look for [this-particular-group-
of-strings], otherwise use a fallback to find them.  Compare whatever
strings you end up with to the word to the left of or under the cursor
and put the longest unambiguous common substring that matches on the
command line, assuming the other styles said that's what you should do.
If there aren't any matches at all, try again with the next completer
until something is found or there are no more completers.

Re: completion

[Bart Schaefer]

On Wed, Jan 7, 2015 at 5:15 PM, Vincent Lefevre <vincent@vinc17.net> wrote:
> On 2015-01-08 03:57:19 +0300, ZyX wrote:
>> I am wondering what happens if completed command contains colon.
>
> I was condering the same thing. Not sure whether this happens in
> practice, but Debian maintainer scripts contain a colon in their
> name.

It would only matter if one of the substrings of the command name
matched one of the substrings of the style definition that was *not* a
wildcard of some kind.  In that case a more stringent style definition
would be needed if by some chance the style name were also valid in
that same context.

Re: completion

[Bart Schaefer]

On Wed, Jan 7, 2015 at 4:43 PM, Vincent Lefevre <vincent@vinc17.net> wrote:
>
> But the ambiguity shouldn't be intentional.

Nevertheless, it is.  Maybe not so much unintentional, as made
unavoidable by the prior constraint that zstyle be a generic lookup
mechanism rather than be tightly coupled to the semantics of
completion contexts.

>       zstyle ':completion:*:complete:*' matcher-list [...]
>
> If * matches everything, then this could mean [any of]
>
>   :completion:[any function]:complete:[any cmd]:[any arg]:[any tag]
>   :completion:[any function]:[any completer]:complete:[any arg]:[any tag]
>   :completion:[any function]:[any completer]:[any cmd]:complete:[any tag]

You're correct, it could.  But "matcher-list" also has to match, and
THAT only happens in one of those three cases, so there's no need to
constrain the pattern any further (unless you WANT to; refer to my
car-cover analogy).

Re: completion

[Bart Schaefer]

On Wed, Jan 7, 2015 at 3:00 PM, Ray Andrews <rayandrews@eastlink.ca> wrote:
> On 01/07/2015 12:42 PM, Bart Schaefer wrote:
>>
>> Globbing:
>> "Show me the dogs in this park that are on a leash." You search the park
>> for dogs, there may be lots but it is an instantaneous finite number.
>>
>> Zstyle:
>> "All dogs in this park must be on a leash." You check every animal you see
>> entering the park to see if it is a dog and has a leash.  You have no idea
>> how many animals or leashes you may eventually find, but if the current
>> animal is a dog, you know it has to have a leash to be allowed in the
>> park.
>>
> I see.  One is 'go find' the other is 'test what comes by', so that's a
> filter really, no?

I'm not sure it's helpful to think about it that way, because
filtering implies that something happens to the thing that's being
filtered, and that's not what the style context does.  It's
descriptive rather than prescriptive, I guess is the way to say it.

> That's very helpful--get the bedrock concepts right--
> but how do we make sense of this in practice?  How do we parse these
> completions, with their varying numbers of colons and asterisks?

You're already on the wrong track when you say "these completions."
These are NOT the completions.  They aren't even descriptions of the
completions.  They're descriptions of the context in which the
completion is being interpreted.

The thing that you want to parse is the context itself.  The problem
to be solved is that, like the dogs that aren't in the park yet, there
are an almost unlimited number of possible contexts.  You can see an
example of a context by invoking the _complete_help binding (default
ctrl+x h), and that example will always have all the colons and none
of the asterisks.  Once you have in mind what a context is, THEN you
can think about what the asterisks mean:  they describe the general
"shape" of all the innumerable contexts to which you might want to
apply the style.

As long as that "shape" fits as closely as you want/need, the number
of colons is irrelevant; only the placement might matter.

> You and
> Peter have both made comments (which I don't understand) that seem to
> suggest that these colons are not what I think they are at all.  But if they
> are not field separators then I can't imagine what they might be.

They are field separators in the context when the implementation of a
completion function looks up a style.  When you are defining the value
of a style, they are more like scaffolding to make sure the "shape"
lines up closely enough with the context.

Here's another silly analogy:  You have three cars, but only a two-car
garage.  So one car is always sitting in the driveway, and you want to
get a canvas cover for it.  If it's always the same car in the
driveway, you can get a cover that has been stitched to fit every
angle and projection of the car down to the spoiler and the rear view
mirrors, and it will fit that one car perfectly.  But if you don't
know which car is going to be stuck in the driveway, you can buy a
generic cover that is long enough and wide enough and goes over any of
the cars like a shapeless bag.  Or you can buy more than one cover and
use whichever one fits best on the car that happens to be sitting in
the driveway today.

The colons in a style DEFINITION are like the detailed stitching in
the canvas.  The colons in a style LOOKUP are like the spoiler and
mirrors.  When zstyle does a lookup, it finds the cover (definition)
that fits the current car (context) the best.

That analogy is incomplete because there's one more component of the
lookup, which is the style name.  You need both the context (which
matches by best fit) AND the name (which matches exactly) to set or
get the value.

Re: completion

[Vincent Lefevre]

On 2015-01-08 03:57:19 +0300, ZyX wrote:
> I am wondering what happens if completed command contains colon.

I was condering the same thing. Not sure whether this happens in
practice, but Debian maintainer scripts contain a colon in their
name.

-- 
Vincent Lefèvre <vincent@vinc17.net> - Web: <https://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Re: completion

[ZyX]

08.01.2015, 03:52, "Vincent Lefevre" <vincent@vinc17.net>:
> On 2015-01-07 10:48:39 -0800, Bart Schaefer wrote:
>>  On Jan 7, 2015 7:15 AM, "Vincent Lefevre" <vincent@vinc17.net> wrote:
>>>  If an asterisk can match anything, there may be an ambiguity on
>>>  which field some given word will match.
>>  This is actually intentional, so that a single style can be applied to
>>  multiple contexts.  The expected use is that the wildcard will usually be
>>  at the tail of the context string, so it's a shorthand to avoid having to
>>  write out all the trailng colons.
>
> But the ambiguity shouldn't be intentional. The syntax is:
>
> :completion:FUNCTION:COMPLETER:COMMAND:ARGUMENT:tag.
> ___________1________2_________3_______4________5

I am wondering what happens if completed command contains colon.

>
> Now consider one of the examples:
>
>       zstyle ':completion:*:complete:*' matcher-list [...]
>
> If * matches everything, then this could mean either
>
>   :completion:[any function]:complete:[any cmd]:[any arg]:[any tag]
>
> or
>
>   :completion:[any function]:[any completer]:complete:[any arg]:[any tag]
>
> or
>
>   :completion:[any function]:[any completer]:[any cmd]:complete:[any tag]
>
> --
> Vincent Lefèvre <vincent@vinc17.net> - Web: <https://www.vinc17.net/>
> 100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/>
> Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Re: completion

[Vincent Lefevre]

On 2015-01-07 10:48:39 -0800, Bart Schaefer wrote:
> On Jan 7, 2015 7:15 AM, "Vincent Lefevre" <vincent@vinc17.net> wrote:
> > If an asterisk can match anything, there may be an ambiguity on
> > which field some given word will match.
> 
> This is actually intentional, so that a single style can be applied to
> multiple contexts.  The expected use is that the wildcard will usually be
> at the tail of the context string, so it's a shorthand to avoid having to
> write out all the trailng colons.

But the ambiguity shouldn't be intentional. The syntax is:

:completion:FUNCTION:COMPLETER:COMMAND:ARGUMENT:tag.
___________1________2_________3_______4________5

Now consider one of the examples:

      zstyle ':completion:*:complete:*' matcher-list [...]

If * matches everything, then this could mean either

  :completion:[any function]:complete:[any cmd]:[any arg]:[any tag]

or

  :completion:[any function]:[any completer]:complete:[any arg]:[any tag]

or

  :completion:[any function]:[any completer]:[any cmd]:complete:[any tag]

-- 
Vincent Lefèvre <vincent@vinc17.net> - Web: <https://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Re: completion

[Ray Andrews]

On 01/07/2015 12:42 PM, Bart Schaefer wrote:
> On Jan 7, 2015 11:51 AM, "Bart Schaefer" <schaefer@brasslantern.com> wrote:
>> The hardest part of the zstyle mechanism is grasping the "reverse pattern
> match" lookup mechanism.  Your hypothetical assassination example is
> inaccurate because you're applying the patterns in the wrong "direction".
>
> Here's possibly a way to think about this.  Let's consider two applications
> of patterns, globbing and zstyle.
>
> Globbing starts with a search space full of very specific objects:
> Individual file names.  You provide a general description (the pattern) and
> globbing looks up all the specific objects.
>
> Zstyle starts with an *empty* search space and a whole lot of very specific
> *searches* (at least one for every possible word-on-the-command-line you
> might want to complete).  These searches are called style contexts.  You
> populate the search space with general descriptions of the style contexts
> you care about, and zstyle looks up the single general description that
> best fits a specific search.
>
> This is why there are wildcards in the commands that set styles.  There are
> no wildcards in the commands that test or look up styles.
>
> Globbing:
> "Show me the dogs in this park that are on a leash." You search the park
> for dogs, there may be lots but it is an instantaneous finite number.
>
> Zstyle:
> "All dogs in this park must be on a leash." You check every animal you see
> entering the park to see if it is a dog and has a leash.  You have no idea
> how many animals or leashes you may eventually find, but if the current
> animal is a dog, you know it has to have a leash to be allowed in the park.
>
I see.  One is 'go find' the other is 'test what comes by', so that's a 
filter really, no?  That's very helpful--get the bedrock concepts 
right-- but how do we make sense of this in practice?  How do we parse 
these completions, with their varying numbers of colons and asterisks?  
You and Peter have both made comments (which I don't understand) that 
seem to suggest that these colons are not what I think they are at all.  
But if they are not field separators then I can't imagine what they 
might be.  (For a while I thought they might be 'emphasizers').  I have 
maybe a dozen or so of these 'zstyle' lines in my .zshrc, and they are 
all there on faith (borrowed from here and there) and I have no idea how 
any of them work. First, let me understand the meta syntax, then I'll 
worry about what goes on inside each field (if that's what they are).

So should we perhaps say 'zstyle filters' vs. 'zstyle searches'? 
'Search' puts me in mind of the globbing thing: go find!

To put it in English, what I'm reaching for (I think), sounds something 
like this:

If [something-on-command-line] matches [this-pattern] (a filter), then 
expand that pattern using [this-particular-set-of-rules], and then 
search (go find) in [this-particular-group-of-objects] for 
[this-particular-glob-pattern] and put that on my command line. I'm 
supposing that that's how it hasta work, but I can't 'see' that in the 
actual syntax.

Re: completion

[Bart Schaefer]

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

On Jan 7, 2015 11:51 AM, "Bart Schaefer" <schaefer@brasslantern.com> wrote:
>
> The hardest part of the zstyle mechanism is grasping the "reverse pattern
match" lookup mechanism.  Your hypothetical assassination example is
inaccurate because you're applying the patterns in the wrong "direction".

Here's possibly a way to think about this.  Let's consider two applications
of patterns, globbing and zstyle.

Globbing starts with a search space full of very specific objects:
Individual file names.  You provide a general description (the pattern) and
globbing looks up all the specific objects.

Zstyle starts with an *empty* search space and a whole lot of very specific
*searches* (at least one for every possible word-on-the-command-line you
might want to complete).  These searches are called style contexts.  You
populate the search space with general descriptions of the style contexts
you care about, and zstyle looks up the single general description that
best fits a specific search.

This is why there are wildcards in the commands that set styles.  There are
no wildcards in the commands that test or look up styles.

Globbing:
"Show me the dogs in this park that are on a leash." You search the park
for dogs, there may be lots but it is an instantaneous finite number.

Zstyle:
"All dogs in this park must be on a leash." You check every animal you see
entering the park to see if it is a dog and has a leash.  You have no idea
how many animals or leashes you may eventually find, but if the current
animal is a dog, you know it has to have a leash to be allowed in the park.

Re: completion

[Ray Andrews]

On 01/07/2015 11:51 AM, Bart Schaefer wrote:
> The hardest part of the zstyle mechanism is grasping the "reverse pattern
> match" lookup mechanism.  Your hypothetical assassination example is
> inaccurate because you're applying the patterns in the wrong "direction".
All I can say is that the 'reverse pattern matching lookup mechanism' is 
less than transparent, in use, or in documentation. Even in 
Peter/Oliver's book, one gets the feeling that even those two masters 
have a sort of 'throw up one's hands' view of it--that one just hopes 
for the best with completion.  This is the deepest well of obscurity in zsh.

Re: completion

[Ray Andrews]

On 01/07/2015 11:33 AM, Lawrence Velázquez wrote:
> On Jan 7, 2015, at 2:24 PM, Ray Andrews <rayandrews@eastlink.ca> wrote:
>
>> And used as a sort of 'wildcard', that would be fine, *but*
>> it shouldn't change the number of separators:
>>
>> kill (  :Ray:*:*:Montreal:*:*: )
> How is this any better than just having empty fields?
>
> This might be an issue in an academic sense, and the documentation should certainly be cleared up, but I'd imagine that anyone actually doing this sort of complex matching would write out the empty fields instead of playing games with asterisks.
I'm not sure, maybe empty fields could mean something different, I'm 
just being verbose.  All I can say with force is that, however this 
asterisk thing works, it sure is not obvious.  I read two docs several 
times over and only got more confused.
> vq

Re: completion

[Bart Schaefer]

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

The zstyle feature and its specific application to completion were
developed by a consensus of people on the zsh-workers list at the time,
several of whom are still present (though not the primary author).

The zstyle mechanism in particular was meant to be very general and in fact
knows nothing of separators.  It's a flat namespace with some put/test/get
semantics wrapped around it.

The needs of the completion system then led to the creation of an
artificial hierarchy within the flat zstyle namespace.  Ranting about *
matching a "separator" colon is like ranting about ellipses skipping over
periods and commas when a paragraph has been abbreviated.

Re: completion

[Bart Schaefer]

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

On Jan 7, 2015 11:25 AM, "Ray Andrews" <rayandrews@eastlink.ca> wrote:
>
> On 01/07/2015 10:48 AM, Bart Schaefer wrote:
>> The expected use is that the wildcard will usually be
>> at the tail of the context string, so it's a shorthand to avoid having to
>> write out all the trailng colons.
>>
> Yabut we mostly see them inside.

Peter and Oliver made a decision when writing the B2Z book to show the full
hierarchy in many examples, but "in real life" so to speak there are not
very many cases where the hierarchy matters.

The hardest part of the zstyle mechanism is grasping the "reverse pattern
match" lookup mechanism.  Your hypothetical assassination example is
inaccurate because you're applying the patterns in the wrong "direction".

Re: completion

[Lawrence Velázquez]

On Jan 7, 2015, at 2:24 PM, Ray Andrews <rayandrews@eastlink.ca> wrote:

> And used as a sort of 'wildcard', that would be fine, *but*
> it shouldn't change the number of separators:
> 
> kill (  :Ray:*:*:Montreal:*:*: )

How is this any better than just having empty fields?

This might be an issue in an academic sense, and the documentation should certainly be cleared up, but I'd imagine that anyone actually doing this sort of complex matching would write out the empty fields instead of playing games with asterisks.

vq

Re: completion

[Ray Andrews]

On 01/07/2015 10:48 AM, Bart Schaefer wrote:
> On Jan 7, 2015 7:15 AM, "Vincent Lefevre" <vincent@vinc17.net> wrote:
>> If an asterisk can match anything, there may be an ambiguity on
>> which field some given word will match.
> This is actually intentional, so that a single style can be applied to
> multiple contexts.  The expected use is that the wildcard will usually be
> at the tail of the context string, so it's a shorthand to avoid having to
> write out all the trailng colons.
>
Yabut we mostly see them inside.  One might at least be
robust about  permitting the asterisk at the end (tho even
then I don't think it's best), but that's not what happens.

And used as a sort of 'wildcard', that would be fine, *but*
it shouldn't change the number of separators:

kill (  :Ray:*:*:Montreal:*:*: )

... kill anyone who's first name is Ray, who roots for the Habs.

And for those who think that brevity should trump clarity:

kill (  :Ray:*:*:Montreal:** )

Re: completion

[Bart Schaefer]

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

On Jan 7, 2015 7:15 AM, "Vincent Lefevre" <vincent@vinc17.net> wrote:
>
> If an asterisk can match anything, there may be an ambiguity on
> which field some given word will match.

This is actually intentional, so that a single style can be applied to
multiple contexts.  The expected use is that the wildcard will usually be
at the tail of the context string, so it's a shorthand to avoid having to
write out all the trailng colons.

Re: completion

[Ray Andrews]

On 01/07/2015 08:58 AM, Mikael Magnusson wrote:
> On Wed, Jan 7, 2015 at 4:28 PM, Peter Stephenson
> <p.stephenson@samsung.com> wrote:
>>
>> If an asterisk can match anything, there may be an ambiguity on
>> which field some given word will match.
>> Yes, they are ambiguous.  The examples probably could do with fixing.
>>
>> With some of the more complicated things you can do, this can actually
>> be hard to work around, I seem to remember.
Thanks Peter, now I know I'm not just too stoopid to understand.

<rant>
"A bit hard to work around"?  It is the work of a demented genius, 
someone who
has an IQ of 140 and the good sense of an over sexed moose.  As Peter 
once said (IIRC) there is no obfuscated code contest in zsh because we 
really don't need one.
I'd rather learn Klingon than learn about asterisks replacing 
separators.  How did this get out of the lab?  Were there only gods 
working on zsh back then?  What happens if the last of the gods gets run 
over by a bus, and there's no one left on the planet who has any idea 
how it works?  Is there anywhere else on the planet where this idea of 
asterisks replacing some arbitrary number of separators would *not* get 
you institutionalized?

<feel better now>

Re: completion

[Peter Stephenson]

On Wed, 7 Jan 2015 17:58:39 +0100
Mikael Magnusson <mikachu@gmail.com> wrote:
> On Wed, Jan 7, 2015 at 4:28 PM, Peter Stephenson
> <p.stephenson@samsung.com> wrote:
> > On Wed, 7 Jan 2015 16:01:09 +0100
> > Vincent Lefevre <vincent@vinc17.net> wrote:
> >> On 2014-12-11 11:34:20 -0800, Ray Andrews wrote:
> >> > Anyway, knowing that the star replaces the colons cracks it open.
> >>
> >> This is a bit old, but... When can an asterisk replace a colon?
> >
> > Colons aren't special to pattern matching at all.
> >
> >> If an asterisk can match anything, there may be an ambiguity on
> >> which field some given word will match.
> >
> > Yes, they are ambiguous.  The examples probably could do with fixing.
> >
> > With some of the more complicated things you can do, this can actually
> > be hard to work around, I seem to remember.
> 
> Does [^:]# work in this context?

Yes, it's just a bit clumsy when repeated in a string.

pws

Re: completion

[Mikael Magnusson]

On Wed, Jan 7, 2015 at 4:28 PM, Peter Stephenson
<p.stephenson@samsung.com> wrote:
> On Wed, 7 Jan 2015 16:01:09 +0100
> Vincent Lefevre <vincent@vinc17.net> wrote:
>> On 2014-12-11 11:34:20 -0800, Ray Andrews wrote:
>> > Anyway, knowing that the star replaces the colons cracks it open.
>>
>> This is a bit old, but... When can an asterisk replace a colon?
>
> Colons aren't special to pattern matching at all.
>
>> If an asterisk can match anything, there may be an ambiguity on
>> which field some given word will match.
>
> Yes, they are ambiguous.  The examples probably could do with fixing.
>
> With some of the more complicated things you can do, this can actually
> be hard to work around, I seem to remember.

Does [^:]# work in this context?

-- 
Mikael Magnusson

Re: completion

[Peter Stephenson]

On Wed, 7 Jan 2015 16:01:09 +0100
Vincent Lefevre <vincent@vinc17.net> wrote:
> On 2014-12-11 11:34:20 -0800, Ray Andrews wrote:
> > Anyway, knowing that the star replaces the colons cracks it open.
> 
> This is a bit old, but... When can an asterisk replace a colon?

Colons aren't special to pattern matching at all.

> If an asterisk can match anything, there may be an ambiguity on
> which field some given word will match.

Yes, they are ambiguous.  The examples probably could do with fixing.

With some of the more complicated things you can do, this can actually
be hard to work around, I seem to remember.

pws

Re: completion

[Vincent Lefevre]

On 2014-12-11 11:34:20 -0800, Ray Andrews wrote:
> Anyway, knowing that the star replaces the colons cracks it open.

This is a bit old, but... When can an asterisk replace a colon?
For instance, in:

      zstyle ':completion:*:*:-redirect-,2>,*:*' file-patterns '*.log'

      zstyle ':completion:*:*:kill:*' verbose no

      zstyle ':completion:*:default' menu ...

      zstyle ':completion:*:sudo::' environ [...]

      zstyle ':completion::complete:cd:*' tag-order [...]

      zstyle ':completion:*:*:rm:*' file-patterns [...]

      zstyle ':completion:*:*:-command-:*' group-order [...]

      zstyle ':completion:*:default' list-colors ${(s.:.)LS_COLORS}

      zstyle ':completion:*:complete:*' matcher-list [...]

etc.

which have one or several missing colons. This is from the
zshcompsys(1) man page.

If an asterisk can match anything, there may be an ambiguity on
which field some given word will match.

-- 
Vincent Lefèvre <vincent@vinc17.net> - Web: <https://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Re: completion

[Ray Andrews]

On 12/11/2014 09:28 AM, Bart Schaefer wrote:
> They are in fact empty fields, but (again quoting section 20.3.1):
Yabut the number of them changes otherwise that's exactly what I'd
have thought  :(
> When looking up styles the completion system uses full context names,
> including the tag.  Looking up the value of a style therefore consists
> of two things:  the context, which may be matched as a pattern, and the
> name of the style itself, which must be given exactly.
>
> Styles are a little inside-out in that the setting contains the pattern
> and the later lookup contains the fixed string to match.
Anyway, knowing that the star replaces the colons cracks it open. I think it
could be  explained better, but I have a prayer of understanding it
now thanks.  Actually the best advice is in the book itself:

"Fortunately, you don't need to understand the details of this syntax
to do most things."

Amen.

Whoever designed this was certainly a genius but he had little mercy
for the regular fella.   I look back at the days when I thought German
grammar was unpleasant, and laugh.

Re: completion

[Bart Schaefer]

On Dec 11,  8:40am, Ray Andrews wrote:
} Subject: Re: completion
}
} > } On 12/10/2014 04:34 PM, Oliver Kiddle wrote:
} > } > The five colons are included because they prevent the completer style
} >
} If there's an explanation of the five colons I've missed it.

Section 20.3.1 Completion System Configuration - Overview

Third paragraph:

The context string always consists of a fixed set of fields, separated
by colons and with a leading colon before the first, in the form
:completion:FUNCTION:COMPLETER:COMMAND:ARGUMENT:tag.
___________1________2_________3_______4________5

A bit later:

The context is gradually put together as the functions are executed,
starting with the main entry point, which adds :completion: and the
FUNCTION element if necessary.  The completer then adds the COMPLETER
element.  The contextual completion adds the COMMAND and ARGUMENT
options.  Finally, the TAG is added when the types of completion are
known.

} And I'm not being theatrical.  If five colons has meaning, then one might
} expect some other number of colons to have meaning as well. I tried to
} understand that as empty fields as well, but the number of colons in
} various examples changes so it can't be a dumb array kind of thing.

They are in fact empty fields, but (again quoting section 20.3.1):

When looking up styles the completion system uses full context names,
including the tag.  Looking up the value of a style therefore consists
of two things:  the context, which may be matched as a pattern, and the
name of the style itself, which must be given exactly.

Styles are a little inside-out in that the setting contains the pattern
and the later lookup contains the fixed string to match.

-- 
Barton E. Schaefer

Re: completion

[Ray Andrews]

On 12/10/2014 09:44 PM, Bart Schaefer wrote:
> On Dec 10,  5:17pm, Ray Andrews wrote:
> } Subject: Re: completion
> }
> } On 12/10/2014 04:34 PM, Oliver Kiddle wrote:
> } > The five colons are included because they prevent the completer style
> } > from matching in other contexts where you might want a different
> } > configuration.
> }
> } They 'prevent' ...  What would not be prevented if there were only four
> } colons?
>
> OK, now you're just being hyperbolic.  Did you not read any of the doc
> that Larry and Oliver mentioned?
Several times.  If there's an explanation of the five colons I've missed it.
And I'm not being theatrical.  If five colons has meaning, then one might
expect some other number of colons to have meaning as well. I tried to
understand that as empty fields as well, but the number of colons in
various examples changes so it can't be a dumb array kind of thing.
>
> In most cases, people write ':completion:*' so as not to care about the
> number of colons.  The Book is just being extra pedantic.
Ah ... this could be the key.  I've not tried to cross reference the 
star against
the extra colons.  I'll reread it with that in mind.

Re: completion

[Bart Schaefer]

On Dec 10,  5:17pm, Ray Andrews wrote:
} Subject: Re: completion
}
} On 12/10/2014 04:34 PM, Oliver Kiddle wrote:
} > The five colons are included because they prevent the completer style 
} > from matching in other contexts where you might want a different 
} > configuration. 
} 
} They 'prevent' ...  What would not be prevented if there were only four 
} colons?

OK, now you're just being hyperbolic.  Did you not read any of the doc
that Larry and Oliver mentioned?

If there were a different number of colons, the style wouldn't match any
context, and would be useless.

} I normally think of code giving instructions to 'do' something. Here 
} it's telling zsh *not* to do something

Let's rephrase Oliver's sentence:

The five colons are included to ensure that the completer style matches
exactly the one context where this configuration applies.

In most cases, people write ':completion:*' so as not to care about the
number of colons.  The Book is just being extra pedantic.

Re: completion

[Ray Andrews]

On 12/10/2014 04:34 PM, Oliver Kiddle wrote:
> The five colons are included because they prevent the completer style 
> from matching in other contexts where you might want a different 
> configuration. 

They 'prevent' ...  What would not be prevented if there were only four 
colons?  What
else would be prevented if there were six?  ten?  How do we know what is 
being prevented?
I normally think of code giving instructions to 'do' something. Here 
it's telling zsh *not*
to do something, but not what it is that it shouldn't do?  I am only 
mortal, this is for the Gods.

Re: completion

[Oliver Kiddle]

Ray Andrews wrote:
> 
> In chapter 10 of 'the book', at one point you start doing this:
> 
>      zstyle ':completion:::::' completer _complete _approximate
> 
> ... I missed any leading explanation of what those five colons
> are doing.

See the grey box on p237.
The part with the colons is the context. The context is decribed using
a colon-separated list of components. This allows for things to be
configured in a context-sensitive manner.

The "completer"s are sort of top-level drivers and are selected very
early while the context is still empty.

The five colons are included because they prevent the completer style
from matching in other contexts where you might want a different
configuration.

> Playing with matcher-list, you have some good ideas there.
> I currently have all that completion/matcher stuff copied in
> from some website of sample .zshrc's  and it was all taken on
> faith, since I hadn't the slightest clue how all that stuff works.
> Since I'm now trying to understand it, the current line I have
> contains this:
> 
>      zstyle ':completion:*' matcher-list    ...   'r:|[._-]=* r:|=* l:|=*'
> 
> ... at the risk of insanity, what is that incantation doing, and
> do I want it?  Gentle generalities are fine.

Matching is the part of the completion system that decides which of the
possibilities match what you have typed on the command-line. By default,
this is just an exact string match of the prefix so given:

  touch one two three
  : t<tab>

It sees that t is a prefix of two and three but not one.

The r:|[._-]=* is roughly saying put a wildcard (*) before . _ or -.
This allows something line w.z.o<tab> to complete to www.zsh.org

It's not unreasonable to use that style. You might want to further limit
the style, however. Matching control can make approximate completion too
aggressive so you might want ':completion:*:(^approximate):*'
Or you might want to restrict it to, e.g. filename completion.
Applicable matching controls are often defined in specific functions so
the one you quote is not that necessary.

Oliver

Re: completion

[Lawrence Velázquez]

On Dec 10, 2014, at 6:15 PM, Ray Andrews <rayandrews@eastlink.ca> wrote:

> In chapter 10 of 'the book', at one point you start doing this:
> 
>    zstyle ':completion:::::' completer _complete _approximate
> 
> ... I missed any leading explanation of what those five colons
> are doing.

I'm not going to attempt an explanation, as the blind should not lead the blind, but the context string format is defined in zshcompsys(1), under "COMPLETION SYSTEM CONFIGURATION" > "Overview".

vq

completion

[Ray Andrews]

Peter, Oliver:

In chapter 10 of 'the book', at one point you start doing this:

     zstyle ':completion:::::' completer _complete _approximate

... I missed any leading explanation of what those five colons
are doing.

Playing with matcher-list, you have some good ideas there.
I currently have all that completion/matcher stuff copied in
from some website of sample .zshrc's  and it was all taken on
faith, since I hadn't the slightest clue how all that stuff works.
Since I'm now trying to understand it, the current line I have
contains this:

     zstyle ':completion:*' matcher-list    ...   'r:|[._-]=* r:|=* l:|=*'

... at the risk of insanity, what is that incantation doing, and
do I want it?  Gentle generalities are fine.

Re: completion

[Ray Andrews]

On 03/12/12 09:44 AM, Ray Andrews wrote:
> Gentlemen:
>
> I'm trying to get command line completion to only offer me lines that 
> are an exact match for what has already been typed.  The number of 
> things you can set in .zshrc is a bit overwhelming. I have all this 
> just for 'completion' and I confess I have little idea what does what:
>
> zstyle ':completion:*' matcher-list 'm:{a-zA-Z}={A-Za-z}'
> zstyle ':completion:*:killall:*' command 'ps -u $USER -o cmd'
> zstyle ':completion:*' menu select
> zstyle ':completion:*' completer _complete _match _approximate
> zstyle ':completion:*:match:*' original only
> zstyle ':completion:*:approximate:*' max-errors 1 numeric
> zstyle ':completion:*:*:kill:*' menu yes select
> zstyle ':completion:*:kill:*' force-list always
> zstyle ':completion:*:cd:*' ignore-parents parent pwd
>
> Can anyone rationalize all that?  I'm going to hack away at it blindly 
> in the mean time, but some fatherly advice would be apreciated.
>
> Tx.
>
Ah! Need to bind up arrow to  history-beginning-search-backward not 
history-search-backward and all is well. Barking up the wrong tree with 
'completion'.  But geez, all this sure is hard to figure out.

completion

[Ray Andrews]

Gentlemen:

I'm trying to get command line completion to only offer me lines that 
are an exact match for what has already been typed.  The number of 
things you can set in .zshrc is a bit overwhelming. I have all this just 
for 'completion' and I confess I have little idea what does what:

zstyle ':completion:*' matcher-list 'm:{a-zA-Z}={A-Za-z}'
zstyle ':completion:*:killall:*' command 'ps -u $USER -o cmd'
zstyle ':completion:*' menu select
zstyle ':completion:*' completer _complete _match _approximate
zstyle ':completion:*:match:*' original only
zstyle ':completion:*:approximate:*' max-errors 1 numeric
zstyle ':completion:*:*:kill:*' menu yes select
zstyle ':completion:*:kill:*' force-list always
zstyle ':completion:*:cd:*' ignore-parents parent pwd

Can anyone rationalize all that?  I'm going to hack away at it blindly 
in the mean time, but some fatherly advice would be apreciated.

Tx.

Re: Completion

[Peter Stephenson]

"Anonymous bin ich" wrote:
> I want to add a completion which lists only those files/directories which
> belong to a certain user(s). Is it possible?

It *should* be possible to do something like this:

  _files_belonging_to_pws() { _path_files -g '*(#qu:pws:)'; }

This basically works, but you'll find that the completion system
adds directories belonging to all users behind your back.  A quick
search suggests this is all part of the undocumented complexity of
_path_files in at least two different ways, so I didn't look further.

-- 
Peter Stephenson <pws@csr.com>                  Software Engineer
CSR PLC, Churchill House, Cambridge Business Park, Cowley Road
Cambridge, CB4 0WZ, UK                          Tel: +44 (0)1223 692070


To access the latest news from CSR copy this link into a web browser:  http://www.csr.com/email_sig.php

To get further information regarding CSR, please visit our Investor Relations page at http://ir.csr.com/csr/about/overview

Completion

[Anonymous bin ich]

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

Hi!

I want to add a completion which lists only those files/directories which
belong to a certain user(s). Is it possible?

[-- Attachment #2: Type: text/html, Size: 134 bytes --]

Completion

[Seth Kurtzberg]

I have a question about zsh completion.  It does just about everything 
exactly the way I want it to after setting up the various configuration 
switches.

There is one problem I don't know how to solve.  When I run the java 
command, zsh will not do completion on arguments following a classpath 
flag (for example, java -classpath . abc/def/ClassFileName).  Can this 
be fixed with a configuration flag?

Thanks in advance,

-----------------------------------------------------------------
Seth Kurtzberg
CTO
ISEC Research and Network Operations Center
480-314-1540
888-879-5206
seth@isec.us
-----------------------------------------------------------------

Re: Completion

[Bart Schaefer]

On Feb 22,  3:24pm, Andy Spiegl wrote:
} Subject: Re: Completion
}
} Say I press TAB after this:
}  $ scp foo me@bar:/usr/local/_
} Then I would like to see the files and directories on the remote host "bar",
} but what I see is the possible completions for my own host.

(A day without a patch is like a day without sunshine.  Hmm, we're having
one of those here right now ...)

The change to _ssh is pretty trival.  A more complex _remote_files is left
as an excercise for those with more free time to kill.

Problems:

(1) It doesn't know from ssh/ssh1/ssh2/scp/scp1/scp2/etc.  But then neither
do the rest of the ssh completions.

(2) Menu completion, at least with auto-menu, appears to execute the remote
command a second time to generate the menu.  (Does this indicate a bug in
the C code?)  That makes it pretty slow for the first two TABs.

(3) There's a remote (pun?) possibility that expansion could interfere when
using expand-or-complete; this might work best with complete-word and the
_expand completer.

(4) Because names are listed with "echo" on the remote host, wildcards are
expanded when generating the completion, even if your styles say not to;
i.e. you get part of the effect of _expand, always.  This could be fixed
by using ${(q)words[CURRENT]#*:}\* in _remote_files, but then expansion
won't work at all.  I think it's OK this way, except possibly that:

(5) Parameter references are expanded on the remote machine when creating
the completions, but on the local machine when the command is executed.

(6) "No match" is handled badly if e.g. the remote login shell is csh.

Index: Completion/User/_ssh
===================================================================
@@ -1,5 +1,11 @@
 #compdef ssh slogin scp ssh-add ssh-agent ssh-keygen
 
+_remote_files () {
+  # This is extremely simple-minded; could parse "ls -F" output to do
+  # colorings and LIST_TYPES and so on, but I'm just not that ambitious.
+  compadd $(ssh ${words[CURRENT]%:*} echo ${words[CURRENT]#*:}\*)
+}
+
 _ssh () {
   local curcontext="$curcontext" state lstate line ret=1 expl args tmp
   typeset -A opt_args
@@ -172,7 +178,7 @@
       return
     elif [[ -n "$state" ]]; then
       if compset -P '*:'; then
-        _files && ret=0
+        _remote_files && ret=0
       elif compset -P '*@'; then
         _wanted hosts expl host && _ssh_hosts -S: "$expl[@]" && ret=0
       else

-- 
Bart Schaefer                                 Brass Lantern Enterprises
http://www.well.com/user/barts              http://www.brasslantern.com

Re: Completion

[Andy Spiegl]

Sven Wischnowsky wrote:

> > Say I press TAB after this:
> >  $ scp foo me@bar:/usr/local/_
> > Then I would like to see the files and directories on the remote host "bar",
> > but what I see is the possible completions for my own host.
> 
> Hm. Depending on what you think about us[1], you may think that we:
> 
> 1) weren't sure if we should do that (and how: using `rsh ... ls' or
>    zftp), because there may be systems without rsh (offering only
>    ssh),
ssh falls back to rsh if there is no ssh on the remote host.
(if configured so)

>    because you may need something like .rhosts for this to work, 
>    which is evil,
Not necessarily: public keys in .ssh/authorized_keys is the better
alternative.

> because it can get pretty expensive, right[2]?
True, but not as expensive as opening a new shell, ssh-ing to the remote
machine and looking for the right path/filenames manually. :-)

> 2) were just too lazy to implement that[3]
I wouldn't call it lazy.  I guess there were and are more important things
to do.  And I wasn't saying that it is bad that zsh doesn't have this
functionality.  I was just asking whether someone on the list has done this 
already so that I don't have to start thinking myself.  So who is lazy? :-)

> [2] This only really means that we should make it configurable: to use 
>     either rsh or zftp or not try remote-completion and so on...
Using ssh with its fallback-to-rsh-option should be enough.  If that fails
a simple "remote host denies access" is sufficient, I would say.

> [3] Actually, I *had* thought about trying to do that, was slightly
>     scared because of 2) and then forgot.
Granted. :-)

Thanks,
 Andy.

-- 
 E-Mail: Andy@spiegl.de     URL: http://andy.spiegl.de
 PGP/GPG: see headers
                                o      _     _         _
  --------- __o       __o      /\_   _ \\o  (_)\__/o  (_)
  ------- _`\<,_    _`\<,_    _>(_) (_)/<_    \_| \   _|/' \/
  ------ (_)/ (_)  (_)/ (_)  (_)        (_)   (_)    (_)'  _\o_
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 I don't feel we did wrong in taking this great country away from them.
 There were great numbers of people who needed new land, and the Indians
 were selfishly trying to keep it for themselves.   (John Wayne)

Re: Completion

[Sven Wischnowsky]

I wrote:

> ...
> (and how: using `rsh ... ls' or
>    zftp)

Oh, and of course, completion for zftp (and the convenience functions
that come with it) works. Including completion of remote files and so on.


Bye
 Sven


--
Sven Wischnowsky                         wischnow@informatik.hu-berlin.de

Re: Completion

[Sven Wischnowsky]

Andy Spiegl wrote:

> Hi Sven,
> 
> > > tcsh has a completion rule like this:
> > >  complete rcp 'c%*@*:%`set q=$:-0;set q="$q:s/@/ /";set q="$q:s/:/ /";set q=($q " ");rsh $q[2] -l $q[1] ls -dp $q[3]\*`%' 'c%*:%`set q=$:-0;set q="$q:s/:/ /";set q=($q " ");rsh $q[1] ls -dp $q[2]\*`%' 'c%*@%$hosts%:' 'C@[./$~]*@f@'  'n/*/$hosts/:'
> > 
> > Urgh. Anyone want to argue about the syntax of compctl or the
> > completion functions again? ;-)
> :-)
> 
> > Eh? The completion system contains functions[1] for rcp and scp, so it
> > should work out-of-the-box.
> Hm, no, not really.  Maybe I am blind (happens too often anyway), but here
> only user@host and option completions are done.  But maybe - from looking
> at the tcsh-code - it was not clear what I meant.

No it wasn't... until I now looked closer and found the calls to `rsh'.

> Say I press TAB after this:
>  $ scp foo me@bar:/usr/local/_
> Then I would like to see the files and directories on the remote host "bar",
> but what I see is the possible completions for my own host.

Hm. Depending on what you think about us[1], you may think that we:

1) weren't sure if we should do that (and how: using `rsh ... ls' or
   zftp), because there may be systems without rsh (offering only
   ssh), because you may need something like .rhosts for this to work, 
   which is evil, because it can get pretty expensive, right[2]?
2) were just too lazy to implement that[3]


Bye
 Sven

[1] I think I wrote the two initially, but I also think someone else
    had his fingers in them after that.
[2] This only really means that we should make it configurable: to use 
    either rsh or zftp or not try remote-completion and so on...
[3] Actually, I *had* thought about trying to do that, was slightly
    scared because of 2) and then forgot.

--
Sven Wischnowsky                         wischnow@informatik.hu-berlin.de

Re: Completion

[Andy Spiegl]

Hi Sven,

> > tcsh has a completion rule like this:
> >  complete rcp 'c%*@*:%`set q=$:-0;set q="$q:s/@/ /";set q="$q:s/:/ /";set q=($q " ");rsh $q[2] -l $q[1] ls -dp $q[3]\*`%' 'c%*:%`set q=$:-0;set q="$q:s/:/ /";set q=($q " ");rsh $q[1] ls -dp $q[2]\*`%' 'c%*@%$hosts%:' 'C@[./$~]*@f@'  'n/*/$hosts/:'
> 
> Urgh. Anyone want to argue about the syntax of compctl or the
> completion functions again? ;-)
:-)

> Eh? The completion system contains functions[1] for rcp and scp, so it
> should work out-of-the-box.
Hm, no, not really.  Maybe I am blind (happens too often anyway), but here
only user@host and option completions are done.  But maybe - from looking
at the tcsh-code - it was not clear what I meant.

Say I press TAB after this:
 $ scp foo me@bar:/usr/local/_
Then I would like to see the files and directories on the remote host "bar",
but what I see is the possible completions for my own host.

Bye,
 Andy.

-- 
 E-Mail: Andy@spiegl.de     URL: http://andy.spiegl.de
 PGP/GPG: see headers
                                o      _     _         _
  --------- __o       __o      /\_   _ \\o  (_)\__/o  (_)
  ------- _`\<,_    _`\<,_    _>(_) (_)/<_    \_| \   _|/' \/
  ------ (_)/ (_)  (_)/ (_)  (_)        (_)   (_)    (_)'  _\o_
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 The reasonable man adapts himself to the world. The unreasonable one
 persists in trying to adapt the world to himself. Therefore, all progress
 depends upon the unreasonable man.   - George Bernard Shaw 

Re: Completion

[Sven Wischnowsky]

Andy Spiegl wrote:

> Hi Bart,
> 
> > zstyle '*:ssh:*:my-accounts' users-hosts tractrix:kom.auc.dk ...
> > zstyle '*:rsh:*:my-accounts' users-hosts alboege:fictitious.com ...
> > 
> > There are also styles that are lists of hosts, users, other-accounts, etc.,
> > but you can cover most of the cases for ssh with just this one.
> Is there anything similar for scp/rcp?
> 
> tcsh has a completion rule like this:
>  complete rcp 'c%*@*:%`set q=$:-0;set q="$q:s/@/ /";set q="$q:s/:/ /";set q=($q " ");rsh $q[2] -l $q[1] ls -dp $q[3]\*`%' 'c%*:%`set q=$:-0;set q="$q:s/:/ /";set q=($q " ");rsh $q[1] ls -dp $q[2]\*`%' 'c%*@%$hosts%:' 'C@[./$~]*@f@'  'n/*/$hosts/:'

Urgh. Anyone want to argue about the syntax of compctl or the
completion functions again? ;-)

> I suppose this could be done in zsh (because everything can be done with
> zsh), but I am still not fit enough with the zsh syntax. :-(  So I would be 
> glad if someone had done it already.

Eh? The completion system contains functions[1] for rcp and scp, so it
should work out-of-the-box.

Bye
 Sven

[1] They are actually functions for the r{sh,login,...} and ssh suites.

--
Sven Wischnowsky                         wischnow@informatik.hu-berlin.de

Re: Completion

[Andy Spiegl]

Hi Bart,

> zstyle '*:ssh:*:my-accounts' users-hosts tractrix:kom.auc.dk ...
> zstyle '*:rsh:*:my-accounts' users-hosts alboege:fictitious.com ...
> 
> There are also styles that are lists of hosts, users, other-accounts, etc.,
> but you can cover most of the cases for ssh with just this one.
Is there anything similar for scp/rcp?

tcsh has a completion rule like this:
 complete rcp 'c%*@*:%`set q=$:-0;set q="$q:s/@/ /";set q="$q:s/:/ /";set q=($q " ");rsh $q[2] -l $q[1] ls -dp $q[3]\*`%' 'c%*:%`set q=$:-0;set q="$q:s/:/ /";set q=($q " ");rsh $q[1] ls -dp $q[2]\*`%' 'c%*@%$hosts%:' 'C@[./$~]*@f@'  'n/*/$hosts/:'

I suppose this could be done in zsh (because everything can be done with
zsh), but I am still not fit enough with the zsh syntax. :-(  So I would be 
glad if someone had done it already.

Bye,
 Andy.

-- 
 E-Mail: Andy@spiegl.de     URL: http://andy.spiegl.de
 PGP/GPG: see headers
                                o      _     _         _
  --------- __o       __o      /\_   _ \\o  (_)\__/o  (_)
  ------- _`\<,_    _`\<,_    _>(_) (_)/<_    \_| \   _|/' \/
  ------ (_)/ (_)  (_)/ (_)  (_)        (_)   (_)    (_)'  _\o_
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 Dew knot trussed spell checquers too fined awl mist takes!

Re: Completion

[Bart Schaefer]

On Feb 15,  9:42am, Claus Alboege wrote:
> Subject: Completion
> 
> Could anyone tell me how to make zsh (3.1.6-*) complete in this fasion:
> 
> ssh <hostname from hostlist> -l <username from userlist>

I'm really surprized no one else has answered this yet ...

zstyle '*:my-accounts' users-hosts tractrix:kom.auc.dk ...

where ... are more strings of the form user:host, will set up zsh's idea
of the accounts that are "you".  These get used for ssh, rsh, and several
other commands that take user, host, or user@host arguments.

You can be more specific if you want:

zstyle '*:ssh:*:my-accounts' users-hosts tractrix:kom.auc.dk ...
zstyle '*:rsh:*:my-accounts' users-hosts alboege:fictitious.com ...

There are also styles that are lists of hosts, users, other-accounts, etc.,
but you can cover most of the cases for ssh with just this one.

Completion

[Claus Alboege]

Hi,

Could anyone tell me how to make zsh (3.1.6-*) complete in this fasion:

ssh <hostname from hostlist> -l <username from userlist>

Sorry for this RTFM like question :)


-- 
Mvh Claus Alboege