From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 22128 invoked by alias); 8 Jan 2015 05:09:44 -0000 Mailing-List: contact zsh-users-help@zsh.org; run by ezmlm Precedence: bulk X-No-Archive: yes List-Id: Zsh Users List List-Post: List-Help: X-Seq: 19711 Received: (qmail 27489 invoked from network); 8 Jan 2015 05:09:41 -0000 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on f.primenet.com.au X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_LOW autolearn=ham version=3.3.2 X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:content-type; bh=FNlyutKTbHzAmKTQotSB7vVOl/C/SqIybJdPMft5Gsw=; b=K2YmRWR1TTjlRAYkY4X/8sEm9LTunyTSqzP4SctrTFcitI0ndHI5Kq/Rji94fMH18l 374jII8fjHGnaARpEq42o1eOYxyDaXez6kgrPUHJ3MUXE2vVQAyYFiu6Utb40YuPOI7k IDWFSk4wRct37gkuG85CTda/9rZEYxba8wL3677F/V8L7GHT6vspVC4XrIAge9w5zHPa K/XgQwpWTyqdZJc0y1D/10kA148VwX+mkUqb5KTHebJzLk7yGlFJ2BAzrcadYcFnA7Ep G2qSdQKs7tzc5DiYfcCMKFBK/aHn7GFO4A5U2jr1nLlMDGL9N0fgX8BiiaqiY0Co+oVN vPOA== X-Gm-Message-State: ALoCoQnsjPIpCe60UYvqKfeNMw8PM0pvdgR41tsEJh5hyoMLHQWphtfp28WVVhUEgtliijM51gsO MIME-Version: 1.0 X-Received: by 10.194.86.135 with SMTP id p7mr14616877wjz.89.1420693777748; Wed, 07 Jan 2015 21:09:37 -0800 (PST) In-Reply-To: <54ADBAA5.4080705@eastlink.ca> References: <5488D414.6010300@eastlink.ca> <30453.1418258082@thecus.kiddle.eu> <5488F0AC.2040901@eastlink.ca> <141210214454.ZM12261@torch.brasslantern.com> <5489C8F4.8030703@eastlink.ca> <141211092824.ZM13349@torch.brasslantern.com> <5489F1BC.5000900@eastlink.ca> <20150107150109.GA14088@ypig.lip.ens-lyon.fr> <54AD8803.4020704@eastlink.ca> <54ADBAA5.4080705@eastlink.ca> Date: Wed, 7 Jan 2015 21:09:37 -0800 Message-ID: Subject: Re: completion From: Bart Schaefer To: Zsh Users Content-Type: text/plain; charset=UTF-8 On Wed, Jan 7, 2015 at 3:00 PM, Ray Andrews 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.