From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 6858 invoked from network); 14 Mar 2000 14:19:32 -0000 Received: from sunsite.auc.dk (130.225.51.30) by ns1.primenet.com.au with SMTP; 14 Mar 2000 14:19:32 -0000 Received: (qmail 25019 invoked by alias); 14 Mar 2000 14:19:14 -0000 Mailing-List: contact zsh-workers-help@sunsite.auc.dk; run by ezmlm Precedence: bulk X-No-Archive: yes X-Seq: 10134 Received: (qmail 24987 invoked from network); 14 Mar 2000 14:19:10 -0000 Date: Tue, 14 Mar 2000 15:19:05 +0100 (MET) Message-Id: <200003141419.PAA05010@beta.informatik.hu-berlin.de> From: Sven Wischnowsky To: zsh-workers@sunsite.auc.dk Subject: tags and all that... (So, was heisst denn `Grundsatzdiskussion' auf Englisch? ;-) I've been thinking a lot about this file-patterns stuff we were discussing. The biggest problem I had with the things suggested was that there suddenly were two loops or loop-like whatevers: the tags and the patterns. If we would make _files use only one tag, say `files' functions like `_next_tags' would be in trouble. So I thought about several ways how _files could be re-organised. For example we could make the file-patterns style be inteded to be set globally, containing tags and patterns for them. _files would then offer all these tags or, if the style is not set, the tags it uses now with the meaning they have now. That would use tag-order and friends as usual. But somehow that didn't feel right. If file-patterns is needed only in certain contexts, one would 1) set it for those contexts and 2) set tag-order for the same contexts, effectively repeating the tag names and if set for a sufficiently specific context, file-patterns could already give the ordering, as suggested by Bart. So I was back to the beginning. Normally I try to generalise the problem in such cases (I at least I wished I would do that always). Being able to specify ones own patterns for files is just a special case. Similar things are already possible with all other types of matches, for example with the ignored-patterns style. That made me think about tags some more. They are kinda schizophrenic currently, aren't they? (And I'm only talking about tags used when adding matches here...) I mean, from a completion function's point of view, tags name `ways to generate matches'. Nothing more. From a user's point of view, they name a set of matches (trying to avoid the word `group' here, which is already used). So, if I may call the `ways to ...' `methods', then we have the connection that completion functions know about one or methods to generate matches and, currently, each method can generate one set of matches. Several styles allow us to say, for example, how the matches in the sets should be displayed (list-packed, list-colors, etc), which matches should not be in them (ignored-patterns) and so on. Coming back to the _files example, we here have the case that we have a function knowing about only one method to create matches, but that can generate different sets of matches. And suddenly the tags named only the sets, not the method (or the method has multiple names, which is equally ugly). So I would like to first make this cleaner, by really separating methods from sets of matches. I.e. functions would not call _tags to say which sets they can generate, they would call, say, _methods to say *how* they can generate matches. These methods would have names. Users could say, which sets of matches they want, they would have names, too. To make things a bit more confusing, let me use `tag' for the name of such a set. So users could say something like: zstyle ... tag-order foo=files bar=files Which means that he wants to use the method `files' twice, generating two sets of matches, named with the tags `foo' and `bar'. Then he can use all the known styles to say, how the matches in the sets are generated, how they are listed and so on. E.g.: zstyle '...:foo' file-patterns '*.ps' Of course, we would have to add some default behaviour. And we should try to make it look like what we have now (that's why I used those styles in the examples). For tag-order that's relatively simple, I think: if a value of tag-order does not contain an `=' (or whatever token we choose): zstyle ... tag-order foo it means, that `foo' is used both to name the method and the set created. _files is probably the most complicated case: it looks at the options it gets (-/, -g, ...) and from that effectively builds a default `table' mapping tags to methods and patterns (globbed-files to whatever was given with -g, directories to `*(-/)', all-files to `*'). But maybe we should make things more method-centered: leave tag-order unchanged and add a new style looked up for the methods: zstyle '...:functions' method-tags non-comp-functions functions zstyle '...:non-comp-functions' ignored-patterns '_*' So, whenever a functions offers to use the method `functions', we try two generate two sets of matches: `non-comp-functions' and `functions'. The tag-order style would then say in which order the tags are tried (and we are back to having to specify tags more than once). On the completion function side this would of course mean that we would have to change all places where _wanted, _tags, etc are used. In places where we now don't need a loop we would have to add one, looping over the tags (sets). Where we now have a loop we would need two nested loop, the outer one looping over the combinations of tags and methods and the inner one looping over the methods, calling them probably more than once, for different tags. Or the outer one looping over the combinations and multiple inner loops looping over the tags. That means that we can hide these tag-loops from completion function writer by putting them into _wanted, _requested and so on (and giveng them what is now after the `&&' as arguments which will be eval'ed). Maybe I'm completely crazy now, maybe all this isn't that big a problem to make is attempt something like this separation of methods and tags. Two things that make me think that it may be worth it are: Andrej (and my) question if it would be possible to have the matcher style behave more like matcher-list. With the splitting one could easily call a method more than once, use different tags and set the matcher style for these tags. The second thing is my unhappiness with all this alternate-set business. I haven't though too much about that yet, but somehow I think there is the potential to get rid of the alternate set altogether (leaving it only be used by compctl). That would make me happy. Actually, the biggest problem I see with all this is to find a good (convenient) way to configure it. I don't like either of the ways I showed above very much. Opinions? Comments? Bye Sven -- Sven Wischnowsky wischnow@informatik.hu-berlin.de