From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 2096 invoked from network); 9 Nov 1999 12:08:15 -0000 Received: from sunsite.auc.dk (130.225.51.30) by ns1.primenet.com.au with SMTP; 9 Nov 1999 12:08:15 -0000 Received: (qmail 21091 invoked by alias); 9 Nov 1999 12:08:02 -0000 Mailing-List: contact zsh-workers-help@sunsite.auc.dk; run by ezmlm Precedence: bulk X-No-Archive: yes X-Seq: 8603 Received: (qmail 21083 invoked from network); 9 Nov 1999 12:08:01 -0000 Date: Tue, 9 Nov 1999 13:07:59 +0100 (MET) Message-Id: <199911091207.NAA21115@beta.informatik.hu-berlin.de> From: Sven Wischnowsky To: zsh-workers@sunsite.auc.dk Subject: completion grouping (yes, again) I've hacked a bit more, trying to make things easier to use and configure... First, the completion function side: `_tags' has been simplified. The `-i' isn't needed anymore, functions that only want to check if a tag (or at least one of a set of tags) is requested at all only need to do `_tags tag... || return 1'. Then I also removed the `-f' option (which was used to give the name of the completion function to test for). Function names are not tested anymore, i.e. the context-patterns are only compared to the command name from the line. I also added a bit of parameter magic, so that functions using `_tags' don't need to define the `tags' parameter locally. In other words, completion function don't have to define *any* local parameter anymore. The I added the functions `_requested' which gets names of tags and returns zero if at least one of these tags was requested. So, to use tags one can now simply do something like: local ret=1 _tags job process # say which types of matches we can add while _tags; do # get the next set of tags to try _requested job && _jobs && ret=0 _requested process && _pids && ret=0 (( ret )) || return 0 done return 1 But there is also the new function `_alternative' (please someone who actually can speak English tell me a better name), which basically implements such a loop. Its arguments are of the form `::', which should look familiar. The tags are given to `_tags' and then a loop executes the actions of the requested tags. This also means that there is a small difference to `_arguments' and friends: the `->state' style for actions is not supported (because `_alternative' may have to execute more than one action). With this functions like `_wait' only have to do: _alternative 'job:: _jobs' 'process:: _pids' (Empty descriptions because they are not used -- the actions start with spaces and we use the descriptions added by `_jobs' and `_pids'.) Then I added some more support for styles. The function `_style' can be used to test if a certain style of completion is requested and to get the string of the style. As a reminder: styles are intended for things like the old `describe_options' config key. The suggested syntax is that in the `comptags' assoc the styles are given in brackets after the priority, seperated by commas and if they have a value, the value is given after an equal sign. E.g. `[s1,s2=foo,s3]'. But never mind, I've have also two suggestions for a better configuration interface (described below) both of which make this very simple. `_style' has four modes: - _style tag style this returns zero if the `style' is set for the `tag' - _style -g tag name this stores the style-string for the `tag' defined by the user in the parameter `name' - _style tag style value this checks if the `style' for the `tag' has the given `value' - _style -g tag style name and this stores the value of the `style' for the `tag' in the parameter `name' Currently only the first mode is used and maybe we should split the function in two: one for testing, one for getting the style/value. Or maybe we'll find out that we don't really need to support values here. What I was thinking about is this: if we integrate the config stuff into the tags mechanism I see two ways we can go: 1) Add `pseudo'-tags, named after the config keys they replace and just use the style defined for them as the replacement for what is now the value of config key. This looks like a good thing to do for keys like `ps_args' and many others. 2) Add new tags which, too, are only used to get information about user definitions, but which also group config keys. For example we could replace the `path_expand'/`path_cursor' pair by making `_path_files' look at the styles for the `pathname' tag (I would hope to find a better name than). `_path_files' would look at the styles `expand' and `cursor' for this tag and the values of these styles are then used like the values of the config keys. I quite like the grouping done by 2), but for some config keys this looks like overkill. One last comment about `_style': currently the arguments are tested literally. We could easily change that so that they are interpreted as patterns. If we ever start using this, it may turn out that we want that... Ok, now for the last part: contexts. The problem is that for some commands there are different places where the same tags are used. E.g. the command `dvips' gets dvi files but any file name after the `-o' option. If we let users define the tags they want to try only based on the command name, cases like this will often show the wrong behaviour. So we would want to be able to say that completion functions generate matches for different contexts and let users define tags differently for these. Back to the example: here we could have a `input' and a `output' context. I have already change `_tags' and `_alternative' to support the `-C ' option that allows one to give the name of the context we are completing for. If such a context is given (currently no functions uses them), `_tags' will compare the patterns from the `comptags' assoc with a string of the form `cmd-name/context'. It could be changed so that a user definition without a slash would affect all contexts. One problem is to decide when we should use such contexts: always? Or only if a command uses the same tag(s) in more than one place? The first one looks cleaner but that would mean that completion function writers would always have to give such a context name. This is particularly ugly because 1) we would have to change all completion functions and 2) we would have to change functions like `_arguments' so that their arguments also contain these context names. Alternatively we could change `_arguments' so that they build default context names if users don't define them. For `_arguments' this could, for example, use names like `-o' and `arg-1' (for options getting multiple arguments this would have to be `-foo-1'). Or maybe we use `arg/1', making it look like a (sub-)sub-context. But, of course, the problem with this is that in many cases the names would be ugly (`infile' is certainly more user-friendly than `arg/1'). Ok, anyone got any ideas about this? And now for the other part: the configuration interface. As I said above, I have implemented two suggestions. The functions are `conf1' and `conf2' in `compinit'. They are not yet in their final form (e.g. they can't list the configuration, only set it, you can look at the result with `comptag'), I just wanted to give you a way to play with them. In the end one or both of them will be removed, renamed and so on... `conf1' is tag-centered, its arguments implement what I would call a mini-language: conf1 ... = tag ... | tag 'is' style = [ ] = 'in' pattern | 'else' = '=' 'never' | '=' number [