From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 3822 invoked from network); 14 Aug 2000 08:02:28 -0000 Received: from sunsite.auc.dk (130.225.51.30) by ns1.primenet.com.au with SMTP; 14 Aug 2000 08:02:28 -0000 Received: (qmail 28218 invoked by alias); 14 Aug 2000 08:02:00 -0000 Mailing-List: contact zsh-workers-help@sunsite.auc.dk; run by ezmlm Precedence: bulk X-No-Archive: yes X-Seq: 12608 Received: (qmail 28211 invoked from network); 14 Aug 2000 08:02:00 -0000 Date: Mon, 14 Aug 2000 10:01:57 +0200 (MET DST) Message-Id: <200008140801.KAA02101@beta.informatik.hu-berlin.de> From: Sven Wischnowsky To: zsh-workers@sunsite.auc.dk In-reply-to: Felix Rosencrantz's message of Sun, 13 Aug 2000 22:51:43 -0700 (PDT) Subject: Re: Completing parameter names that have yet to be set. Felix Rosencrantz wrote: > I was unaware of the "fake" style. I just looked at _parameter before > posting. It seems that "fake" covers the functionality I was thinking > about for files. It seems that _parameters also needs the ability to > fake values as my copy does. There probably are other places where fake > could be used. As I said, that's why I used a generic name (I haven't thought of other places where it may be useful yet, though). > ... > > It seems whatever format is used for "fake-parameters", it should allow > the user to specify descriptions. Also type information would be nice. That may be another difference, I think. I.e., I'm not sure if the descriptions are useful everywhere. In the case of the fake-style-for- files, listing them separately may get a bit complicated (control-flow- wise in _path_files). Question to everyone: should we change `fake' to `fake-files' now? And how important do you consider allowing users to give a (optional) description for them? (I.e.: for the faked *files*.) > One thing I really like about the fake style used for files is that > it provides a mechanism for context based on the directory of the > completion. I've wondered if there is a way to generalize this so that > other styles could be based on the directory of completion (or other > information). > > The completion system has so many styles that allow the user to tweak > completion. All these different styles provide hooks to the various > tools of the completion. Different situations require different tools. Note the word `tools'. Isn't that synonym for `commands' here? Anyway, one can always program that with `zstyle -e', I think. (But yes, in this case at least, the directory where we complete in is indeed context information. I don't have the slightest idea where we could make that information available for easy matching, though. I mean, a completion-context with a pathname in it looks weird. And to allow to specify the glob patterns based in it we would have to test it in _files, and _path_files (if it was called directly). Hm.) > ... > > It seems that the ability to configure styles based on additional > information not found in the context requires the ability to treat a > group of styles as a single whole, and quickly set/unset a group of > styles. I vaguely remember something like this was talked about, but > don't remember what was decided. I only said several times that I would wish I had an idea how to do that ;-) This kind of feeling comes from the times when I wished we had easy ways to support multiple sets of , e.g. histories, key bindings, etc. Bye Sven -- Sven Wischnowsky wischnow@informatik.hu-berlin.de