From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 25598 invoked from network); 20 Sep 1999 13:36:28 -0000 Received: from sunsite.auc.dk (130.225.51.30) by ns1.primenet.com.au with SMTP; 20 Sep 1999 13:36:28 -0000 Received: (qmail 18963 invoked by alias); 20 Sep 1999 13:36:05 -0000 Mailing-List: contact zsh-workers-help@sunsite.auc.dk; run by ezmlm Precedence: bulk X-No-Archive: yes X-Seq: 7958 Received: (qmail 18923 invoked from network); 20 Sep 1999 13:36:02 -0000 Date: Mon, 20 Sep 1999 15:35:54 +0200 (MET DST) Message-Id: <199909201335.PAA07280@beta.informatik.hu-berlin.de> From: Sven Wischnowsky To: zsh-workers@sunsite.auc.dk In-reply-to: Sven Wischnowsky's message of Fri, 17 Sep 1999 11:43:42 +0200 (MET DST) Subject: completion groups (was: Re: PATCH: _cd) I wrote: > Some time ago we had some people here asking if it were possible to > see first only, say, `*.tar' files and then hit some to to get the > directories. Now we have this discussion about showing options or > not. Why not combine them? What I'm thinking about is a combination of > a completer that would be stuck in front of the `completer' key and > uses some config keys and/or parameters/arrays/whatevers to set up > some completion-system-global parameter(s). These are then used by all > completion functions concerned to find out which matches should be > generated (and how, thinking about descriptions). And with (an > improved (and renamed) version of) `_verbose_list' one could get this > `first-this-and-then-that' behaviour. I've thought some more about this over the weekend (trying to avoid hacking the nested-braces and the nested-quotes problem which look more and more complicated...). I think I'd like to make this an integral part of the completion system (no extra completer function). It would go like this: We have a helper function, say `requested' which gets one (but see below) argument, a `tag'. This function uses some keys or (probably needed) parameters (arrays) that describe what kind of matches the user wants to have generated. This description may be a list of tags and if the tag given as argument is in that list, `requested' returns zero, non-zero otherwise. The description may also be a number, so that if it is `1', `_requested' return only zero the first time it is called, if it is `2' the second time and so on. It should be possible to specify the tag-lists in a way depending on: the command on the line, the word on the line (so that we could get the `option_prefix' behaviour with this mechanism, too), and, maybe, even based on some other information which may be given as argument to `_requested'. What I'm thinking about here is `_files': it could give the `-g' pattern it gets to `_requested' and one could then specify that one wants to see directories immediatly whenever a tar-file is completed, but not if a executable is completed (stupid example, but I hope you understand what I mean). Anyway, with that every well-behaved completion function (especially those that add different types of matches) would do something like: if _requested foo; then ... fi The `_files' example that brought all this up is a bit of a special case. We could either use the syntax Peter suggested to make it try different file types, each with a call to `_requested' or we could add an option which says `also complete directories if the user wants to see them immediatly'. Or we could make `_files' always do that unless some new option is given. The `_requested' function would also store the tags given by all calls to it and all tags for which zero/non-zero was returned in arrays so that other functions could have a look at this. One function (or a set of functions) using this would be the replacement for `_verbose_list' giving much more detailed control over what should be listed or what should be completed next. We could have commands to cycle through the different tag-groups, commands to temporarily augment the list of tags to use, heck, we could even have a command that first runs completion to only get the tags, offers these to the user and lets him select those he wants to see (although that would give a style of completion I certainly couldn't get used to ;-). The biggest problem I see with this (and for which I don't have a good solution yet) is how we choose the tags. If every function that adds different types of matches uses tags roughly describing the type this would obviously result in a plethora of tags and users would have to keep monstrous lists of tags they want to see. We could allow descriptions like `everything except...' (this would probably be useful to have anyway). Or we could have a set of standard names (like normal/alternate, primary/secondary, ...). This could be combined with making `_requested' accept multiple tags as arguments so that a function like `_kill' would use `_requested normal jobs' and `_requested alternate pids'. But all this isn't really satisfying, I think, because then the user would still sometimes get matches he doesn't want to see on the first completion attempt just because some functions use the same tag. And depending on the way we want to look at it, this is probably even a bit more complicated if we think about things like options and their descriptions (this is not only constrained to options and values if we want let users say if they want to see the long displays we use the `-d' option for or not). Here we really have some kind of sub-tag (`options' versus `options-with- descriptions'). Ok, what do you think. Is any of this interesting enough for enough people to work on or have I just gone mad (or both?). For those who like this: any suggestions for the tags-problem or comments or whatever? Bye Sven -- Sven Wischnowsky wischnow@informatik.hu-berlin.de