From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 162 invoked from network); 25 Nov 1999 09:54:50 -0000 Received: from sunsite.auc.dk (130.225.51.30) by ns1.primenet.com.au with SMTP; 25 Nov 1999 09:54:50 -0000 Received: (qmail 11018 invoked by alias); 25 Nov 1999 09:54:40 -0000 Mailing-List: contact zsh-workers-help@sunsite.auc.dk; run by ezmlm Precedence: bulk X-No-Archive: yes X-Seq: 8777 Received: (qmail 11009 invoked from network); 25 Nov 1999 09:54:38 -0000 Date: Thu, 25 Nov 1999 10:54:37 +0100 (MET) Message-Id: <199911250954.KAA03611@beta.informatik.hu-berlin.de> From: Sven Wischnowsky To: zsh-workers@sunsite.auc.dk In-reply-to: Sven Wischnowsky's message of Wed, 24 Nov 1999 11:44:03 +0100 (MET) Subject: Re: Questions (and PATCH: small change to _complete) I wrote: > ... > > When completing in command position, _normal appends `-complete-' to > the context name (e.g. `:complete:-command-'). This is fine. When > completing arguments of commands, however, it only appends the command > name (e.g. `:complete:dvips'). I'm a bit worried that someday we will > find out that we have used a tag name that is also the name of a > command and then it's non-trivial to write a compstyle-pattern that > correctly matches only the command name. Ouch ;-) There was already the cvs tag. 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'. Maybe this is even bettern than inserting `-argument-' or some such. Saves some typing. And I forgot to say that before the next release we should make sure that we set up good defaults for styles and probably improve the default _sort_tags. But I think this should really be done at the end. Bye Sven diff -u -r oldcompletion/Core/_normal Completion/Core/_normal --- oldcompletion/Core/_normal Wed Nov 24 17:06:54 1999 +++ Completion/Core/_normal Thu Nov 25 10:47:30 1999 @@ -26,14 +26,16 @@ if [[ "$command[1]" == '=' ]]; then eval cmd1\=$command cmd2="$command[2,-1]" + curcontext="${curcontext}::${cmd1}:" elif [[ "$command" == */* ]]; then cmd1="$command" cmd2="${command:t}" + curcontext="${curcontext}::${cmd1}:" else cmd1="$command" cmd2="$commands[$command]" + curcontext="${curcontext}::${cmd1}:" fi - curcontext="${curcontext}:${cmd1}" fi # See if there are any matching pattern completions. diff -u -r oldcompletion/Core/_sort_tags Completion/Core/_sort_tags --- oldcompletion/Core/_sort_tags Wed Nov 24 17:06:55 1999 +++ Completion/Core/_sort_tags Thu Nov 25 10:51:31 1999 @@ -6,17 +6,17 @@ case "$curcontext" in # Some silly examples commented out: # -# *p[bgpn]m*) # change the order for file-completion +# *::*p[bgpn]m:*) # change the order for file-completion # comptry globbed-files directories # comptry all-files # ;; -# *:dvips:-o*) # automatic context set by _arguments +# *::dvips::-o*) # automatic context set by _arguments # comptry all-files # return # ;; -# *:kill:*) +# *::kill:*) # comptry processes -# return # this return ensures that we use only processes +# return # this return ensures that we use only processes # ;; *) comptry globbed-files diff -u olddoc/Zsh/compsys.yo Doc/Zsh/compsys.yo --- olddoc/Zsh/compsys.yo Wed Nov 24 17:06:32 1999 +++ Doc/Zsh/compsys.yo Thu Nov 25 10:50:22 1999 @@ -309,14 +309,19 @@ The completion system represents such a context as a hierarchical name with components separated by colons. For example the name -tt(:complete:dvips:-o-1) is used when completing the first argument of +tt(:complete::dvips::-o-1) is used when completing the first argument of the tt(-o) option of the tt(dvips) command. The tt(:complete) at the beginning just says that we are currently trying completion as opposed to, say, correction, which can also be done using the function based completion system (see ifzman(the section `Control Functions' below)\ ifnzman(noderef(Control Functions)) -for more information). +for more information). And the tt(::dvips:) shows that we are +completing arguments for the tt(dvips) command. Such a doubled colon +will appear only before and after the name of the command, but note +that the second colon after the command name is really only added when +there is at least one more component (otherwise the whole name ends in +a colon). In many of the possible contexts the completion system can generate matches, and often it can generate multiple types of matches. Whenever @@ -344,7 +349,7 @@ example(_sort_tags() { case $curcontext in - (*:dvips:*) + (*::dvips:*) comptry globbed-files directories comptry all-files ;; @@ -419,7 +424,7 @@ example(_sort_tags() { ... case $curcontext in - (*:kill:*) + (*::kill:*) comptry processes return ;; @@ -481,7 +486,7 @@ calling the tt(ps) command). To make this builtin list the matches only as numbers one could call: -example(compstyle '*:kill:*' description no) +example(compstyle '*::kill:*' description no) And if one wants to see the command lines for processes but not the job texts one could use the fact that the tag name is appended to the @@ -489,14 +494,14 @@ call use (remember that the function for the tt(kill) builtin command uses the tags tt(jobs) and tt(processes)): -example(compstyle '*:kill*:jobs' description no) +example(compstyle '*::kill:*:jobs' description no) As said above, the patterns given to the tt(compstyle) function are tested in the order in which they were given. But that isn't completely true. In fact, this function roughly sorts the patterns so that more specialized patterns are compared before more general patterns. Due to this, the last two examples could be defined after -the first one because both `tt(*:kill:*)' and `tt(*:kill*:jobs)' are +the first one because both `tt(*::kill:*)' and `tt(*::kill:*:jobs)' are considered to be more specific then the pattern `tt(*)' from the first example. To decide how specific a pattern is, the function looks at the number of colons (corresponding to the number of components) used -- Sven Wischnowsky wischnow@informatik.hu-berlin.de