From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 28160 invoked from network); 30 Nov 1999 08:36:00 -0000 Received: from sunsite.auc.dk (130.225.51.30) by ns1.primenet.com.au with SMTP; 30 Nov 1999 08:36:00 -0000 Received: (qmail 13809 invoked by alias); 30 Nov 1999 08:35:53 -0000 Mailing-List: contact zsh-workers-help@sunsite.auc.dk; run by ezmlm Precedence: bulk X-No-Archive: yes X-Seq: 8801 Received: (qmail 13802 invoked from network); 30 Nov 1999 08:35:52 -0000 Date: Tue, 30 Nov 1999 09:35:51 +0100 (MET) Message-Id: <199911300835.JAA23996@beta.informatik.hu-berlin.de> From: Sven Wischnowsky To: zsh-workers@sunsite.auc.dk In-reply-to: "Bart Schaefer"'s message of Mon, 29 Nov 1999 17:23:56 +0000 Subject: Re: Questions (and PATCH: small change to _complete) Bart Schaefer wrote: > ... > > ZLS_COLORS is a colon-separated list already, isn't it? Potentially > pretty confusing to use a colon within an element as well as between. > Using a second '=' might be better: > > ZLS_COLORS='foo=[A-Z]*=47' Ahem, right. > ... > > } The question, however, is, where we get those group names from. [...] > } why not use the tag names as group names. > > I think this is a good idea. Further, in the syntax above, group-name > could be a pattern (including alternations with `(...|...)') to easily > assign the same file-type and color-code to multiple groups. Yes. > } About the ordering of the groups in the list (i.e. which type of > } matches appears at the top, below that, ..., at the bottom): [...] > } I suggested a special parameter that gives the names of the groups > } already added and if a user modifies this, the order in which he uses > } the group names defines the order in which they appear in the list. > > This is probably fine. One issue is what to do with any groups that > the user deletes from the value of the parameter. Don't display them > at all? Display them last? Produce an error of some kind? And what > happens if the same group is added again later by some other completer? Yes, I've been wondering about this, too. Part of the reason why I made the other suggestion: > } And here, too, we have the question of how we can > } make this easily configurable. The most convenient way might be in > } _sort_tags with an interface a bit like comptry. I.e. a builtin or > } function that is called multiple times and gets one or more tags as > } arguments. The matches for the tags from the first call are all put in > } the first group, those from the second call are put in the second > } group, etc. If this is a builtin, we could even make it do some hidden > } magic (creating empty groups with the right names and in the right > } order) so that we wouldn't have to use the array-with-group names > } business > > I'm not sure I follow this. It would be up to _sort-tags to call this > proposed builtin with each tag in the right sequence, to create the > sorted list? I think separating the grouping of the matches from the > sorting of the groups is the way to go ... does what you're proposing > there handle that in some way? I really had that idea while writing that message, I hadn't thought about everything yet. Doing it in _sort_tags was just the first thought because that's the place users fiddle with tags/groups anyway. But I wasn't happy with throwing different controls together again after we finally found a way to separate the tags and styles. Hm, maybe I can think of something better, especially with the default behaviour I'd like to achieve (mentioned in 8797). > } (and then that array wouldn't be in the way if we ever add a > } possibility to access the matches and groups added in a later > } release). > > I don't see how the array would be "in the way". It can serve the dual > purpose of ordering the groups and of making their names known so that > you know what groups it's sensible to ask for when accessing them. To be able to define ordering of groups with such an array, we would have to use a normal array. If we ever want to give raw access to the matches and match-groups added we probably would want to use an assoc with the group names as keys and some information about the groups as the values (number of first/last match or whatever). Then we would have either both or something which will probably be uglier than only one assoc. I think. But I may be wrong. > On Nov 26, 9:46am, Sven Wischnowsky wrote: > } Subject: PATCHlet: was: Re: Questions (and PATCH: small change to _complet > } > } Bart Schaefer wrote: > } > } > On Nov 25, 10:54am, Sven Wischnowsky wrote: > } > } For now this patch makes command names be preceded and followed by two > } > } colons. I.e. to unambiguously match the command name you can now do > } > } `*::cvs:*' and to test for a command/tag combination: `*::command:*:tag'. > } > > } > This only solves the problem in one direction, doesn't it? > } > } The tag name is always the *last* component (and there is always only > } one). In fact, it isn't really part of the context name stored in > } $curcontext. > > Here's a question ... why isn't $curcontext an array? Is it really an > advantage for it to be a colon-separated string? And if it is, why not > tie the regular array to a colon-array and get both for free? I used the colon-separated string because 1) I liked making them look a bit like other hierarchical names users already know (pathnames, of course) and 2) it was clear from the beginning that they would be used for pattern matching and `*:dvips:-o*' looks more friendly than `*" dvips -o"*' or some such. However, if we use an array, we could make this look like one of those X.400 names: ( completer=complete command=dvips option=-o argument=1 tag=all-files) Maybe going a bit too far? Or maybe not... And would probably call for help by some builtin to define patterns for such names. But still, saving and restoring these things would be costlier than the simple `local curcontext="$curcontext"' we have now. Why not a tied array? Because I always forget that we have them. And the main question: as long as we don't use the `...=...' syntax above, when do we need to access single components? Currently we don't. Bye Sven -- Sven Wischnowsky wischnow@informatik.hu-berlin.de