From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 28194 invoked from network); 15 Nov 1999 12:31:14 -0000 Received: from sunsite.auc.dk (130.225.51.30) by ns1.primenet.com.au with SMTP; 15 Nov 1999 12:31:14 -0000 Received: (qmail 22972 invoked by alias); 15 Nov 1999 12:31:06 -0000 Mailing-List: contact zsh-workers-help@sunsite.auc.dk; run by ezmlm Precedence: bulk X-No-Archive: yes X-Seq: 8643 Received: (qmail 22965 invoked from network); 15 Nov 1999 12:31:05 -0000 Date: Mon, 15 Nov 1999 13:30:55 +0100 (MET) Message-Id: <199911151230.NAA32145@beta.informatik.hu-berlin.de> From: Sven Wischnowsky To: zsh-workers@sunsite.auc.dk In-reply-to: "Bart Schaefer"'s message of Thu, 11 Nov 1999 17:42:38 +0000 Subject: Re: New configuration -- should we... [ I wanted to reply to this on Friday and then forgot... sorry. ] Bart Schaefer wrote: > } > One further thought, at the risk of distraction: Aren't these tags just > } > describing more contexts? That is, what we're really trying to do is > } > split the whole system into stages: (1) determine context, (2) generate > } > appropriate matches, (3) organize matches for display. The farther apart > } > we can drive these, the better; maybe there's even some way to cause the > } > tags to become context-keys for _normal, or the equivalent? > } > } I'm not entirely sure what you mean by (3). For now I'll take it as > } `say how the matches should be generated'. I.e. things like `always', > } `only if a certain prefix is on the line' `with descriptions if > } possible' (maybe you also meant `how they are sorted in the list' -- > } group-wise sorted, that is?). Anyway, this is the stuff I suggested > } the styles for. > > For (3) I thought almost entirely of `how groups are sorted in the list' > and `order by rows or by columns' and maybe even `use menu-completion or > menu-selection' and that kind of thing. `always' or `only if a certain > prefix is on the line' are part of (1); `with descriptions if possible' > is a part of (2). First aside: This reminded me that I wanted to make the options affecting completion be controllable via $compstate. I had forgotten to do that for the new list options. Second aside: Hm, wouldn't users probably think that `with descriptions if possible' is part of (3), even if it is part of (2) for the completion function writer? We could make things like these configurable via styles, too. I.e. I don't see a reason for using a different configuration mechanism for things like that. It would then affect groups of matches as a whole which I like anyway. But that would also mean that a) it is even more important that everyone uses `_description' whenever adding matches and b) that we should always use grouping (otherwise we can't really control such things on a per-group basis). We could then even implement styles that allow users to say if they want the group sorted and/or uniquified. And we could make the new listing-options be settable per-group and let users define which types of matches they want packed. Some of the things (like menu-completion), however, can obviously not be controlled on a per-group basis. Only in the sense of `if there *are* any matches in this group (meaning: for this tag)', then use menu-completion or -selection or whatever. Another thing would be the naming of groups. The completion system heads into the direction of having a one-to-one relationship between tags and groups. We could make the group names (the ones used internally) be configurable, defaulting to the tag-name. Users could then specify if they want to put matches for different tags into the same group by specifying mappings from tags to group names. The `how groups are sorted in the list' finally is probably the most interesting one but also the most complicated. The problem is that the completion code just displays the groups in the order in which they were added. So we would either have to implement a way so that completion functions can change that order before the completion code starts listing the stuff or we would have to make the completion system actually add the groups in a different order. For that we would have to change the tag-loops we have now into two nested loops. Hm. The first one reminds me of the access-to-match-information stuff I've been talking about sometimes. Maybe if we had a special array containing the names of the groups added (or an association mapping group names to some information) we could allow users to modify that array and the completion code would then use the groups in the order in which they appear in the array after the widget has returned. I can't think of a good way to configure this, though. Bye Sven -- Sven Wischnowsky wischnow@informatik.hu-berlin.de