Re: completion

[Bart Schaefer <schaefer@xxxxxxxxxxxxxxxx>]

On Wed, Jan 7, 2015 at 3:00 PM, Ray Andrews <rayandrews@xxxxxxxxxxx> 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.