* Completing a unique prefix of "script" completes "script" @ 2006-08-10 20:17 ` Nikolai Weibull 2006-08-10 21:41 ` Peter Stephenson 0 siblings, 1 reply; 16+ messages in thread From: Nikolai Weibull @ 2006-08-10 20:17 UTC (permalink / raw) To: Zsh Users' List Yes, it's true, that's precisely what you'd expect. However, when working with ruby-on-rails, you often run scripts in the "script" subdirectory. This is made somewhat harder by the fact that util-linux installs a program called "script" in your bindir. Thus, whenever you're in a ruby-on-rails root-directory you wind up completing a unique prefix of "script" as "script ", i.e., with the added space and completion is finished. But I never want to complete that script command. What I want is the completion of the directory name. Is there a way to make sure that both options, i.e., "script/" and "script ", are completed? Also, is there a way to ignore the command "script" found in $path? Using the ignored-patterns style doesn't work, of course. And that's basically the only thing I was able to think of. Up until a non-unique prefix both "script" as a command and "script/" as an executable or directory are listed. nikolai ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: Completing a unique prefix of "script" completes "script" 2006-08-10 20:17 ` Completing a unique prefix of "script" completes "script" Nikolai Weibull @ 2006-08-10 21:41 ` Peter Stephenson 2006-08-13 14:49 ` Nikolai Weibull 2006-08-13 14:59 ` Nikolai Weibull 0 siblings, 2 replies; 16+ messages in thread From: Peter Stephenson @ 2006-08-10 21:41 UTC (permalink / raw) To: Zsh Users' List "Nikolai Weibull" wrote: > Is there a way to make sure that both options, i.e., "script/" and > "script ", are completed? This is all rather frustrating, yet again... Looks like you can get this with the combination of "setopt autocd" to have local directories completed and "zstyle ':completion:*' group-name ''" to separate groups, so that it knows that it's ok to have both matches for "script" separately. I'm not sure why you would need autocd---that looks like a bug, since you can execute commands by relative paths anyway. That's still not it, however, since you only get both if the completion is otherwise ambiguous (i.e. script and script/ aren't sufficiently different to show up separately). Bizarrely, playing around suggests my matcher-list is enough to make them appear "different": zstyle ':completion:*' matcher-list 'm:{a-zA-Z}={A-Za-z}' 'r:|[.,_-]=**r:|=**' > Also, is there a way to ignore the command "script" found in $path? > Using the ignored-patterns style doesn't work, of course. And that's > basically the only thing I > was able to think of. You should be able to do it with the tag-order style so that it prefers the directory if it's found. However, there's something a bit screwy here, too. zstyle :completion::complete:-command-:: tag-order local-directories should prefer local directory completion to everything else, only offering other stuff if there's no local directory (or if you explicitly use _next_tags). But that doesn't work; you get all possibilities together. Explicitly listing other possibilities in a second argument doesn't work, either. However, it's not completely broken since zstyle :completion::complete:-command-:: tag-order local-directories - does work; that gives you only local directories and nothing else. So for some reason as soon as you try to specify an order it's assuming you don't want an order. You can cheat and unhash the command if you never use it. "unhash script" did seem to do the trick. Note, however, that a "rehash" will bring it back. That's about five things I don't understand. -- Peter Stephenson <p.w.stephenson@ntlworld.com> Web page now at http://homepage.ntlworld.com/p.w.stephenson/ ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: Completing a unique prefix of "script" completes "script" 2006-08-10 21:41 ` Peter Stephenson @ 2006-08-13 14:49 ` Nikolai Weibull 2006-08-14 12:12 ` Peter Stephenson 2006-08-13 14:59 ` Nikolai Weibull 1 sibling, 1 reply; 16+ messages in thread From: Nikolai Weibull @ 2006-08-13 14:49 UTC (permalink / raw) To: Peter Stephenson; +Cc: Zsh Users' List On 8/10/06, Peter Stephenson <p.w.stephenson@ntlworld.com> wrote: > "Nikolai Weibull" wrote: > > Is there a way to make sure that both options, i.e., "script/" and > > "script ", are completed? > You can cheat and unhash the command if you never use it. "unhash > script" did seem to do the trick. Note, however, that a "rehash" will > bring it back. It seems that the hash table is initialized after .zshrc is read. Is there a way to run some scripts after everything is initiaziled? I just stuck [[ -n $(whence script) ]] && unhash script in my .zshrc and figured that it'd work ($path being set in my .zprofile). That failing, I put a "rehash" before that line. I still get /home/now/.local/etc/zsh/.zshrc:unhash:36: no such hash table element: script What am I missing? And thanks for the very complete answer. Too bad none of the solutions seem to work very well. nikolai ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: Completing a unique prefix of "script" completes "script" 2006-08-13 14:49 ` Nikolai Weibull @ 2006-08-14 12:12 ` Peter Stephenson 2006-08-14 22:36 ` Nikolai Weibull 0 siblings, 1 reply; 16+ messages in thread From: Peter Stephenson @ 2006-08-14 12:12 UTC (permalink / raw) To: zsh-users "Nikolai Weibull" <now@bitwi.se> wrote: > It seems that the hash table is initialized after .zshrc is read. Is > there a way to run some scripts after everything is initiaziled? Hmm... I haven't looked at the source but in my case it seems to be being hashed straight away... zsh -f -c 'zmodload -i zsh/parameter print $commands[script] unhash script print $commands[script]' prints /usr/bin/script the first time and nothing the second time. /etc/zshenv is empty. Aha---it looks like zsh/parameter is filling the hash table itself (based on the HASHLISTALL option which is on by default). So maybe putting zmodload -i zsh/parameter early in your initialization file (it'll probably be loaded by the completion system later anyway) is good enough. -- Peter Stephenson <pws@csr.com> Software Engineer CSR PLC, Churchill House, Cambridge Business Park, Cowley Road Cambridge, CB4 0WZ, UK Tel: +44 (0)1223 692070 To access the latest news from CSR copy this link into a web browser: http://www.csr.com/email_sig.php ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: Completing a unique prefix of "script" completes "script" 2006-08-14 12:12 ` Peter Stephenson @ 2006-08-14 22:36 ` Nikolai Weibull 0 siblings, 0 replies; 16+ messages in thread From: Nikolai Weibull @ 2006-08-14 22:36 UTC (permalink / raw) To: Peter Stephenson; +Cc: zsh-users On 8/14/06, Peter Stephenson <pws@csr.com> wrote: > "Nikolai Weibull" <now@bitwi.se> wrote: > > It seems that the hash table is initialized after .zshrc is read. Is > > there a way to run some scripts after everything is initiaziled? > > Hmm... I haven't looked at the source but in my case it seems to > be being hashed straight away... > > zsh -f -c 'zmodload -i zsh/parameter > print $commands[script] > unhash script > print $commands[script]' > > prints /usr/bin/script the first time and nothing the second time. > /etc/zshenv is empty. Aha---it looks like zsh/parameter is filling the > hash table itself (based on the HASHLISTALL option which is on by default). > So maybe putting > > zmodload -i zsh/parameter > > early in your initialization file (it'll probably be loaded by the completion > system later anyway) is good enough. Nope. It seems zmodload returns before the hash table is fully initialized. If I put a "sleep 1" in there it works, but without it it'll still complain about the command not being hashed. Actually, a "sleep 0" seems to work as well... That's /one/ thing /I/ don't understand... nikolai ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: Completing a unique prefix of "script" completes "script" 2006-08-10 21:41 ` Peter Stephenson 2006-08-13 14:49 ` Nikolai Weibull @ 2006-08-13 14:59 ` Nikolai Weibull 2006-08-13 16:34 ` Peter Stephenson 1 sibling, 1 reply; 16+ messages in thread From: Nikolai Weibull @ 2006-08-13 14:59 UTC (permalink / raw) To: Peter Stephenson; +Cc: Zsh Users' List On 8/10/06, Peter Stephenson <p.w.stephenson@ntlworld.com> wrote: > zstyle ':completion:*' matcher-list 'm:{a-zA-Z}={A-Za-z}' 'r:|[.,_-]=**r:|=**' What exactly are the 'r's doing here? nikolai ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: Completing a unique prefix of "script" completes "script" 2006-08-13 14:59 ` Nikolai Weibull @ 2006-08-13 16:34 ` Peter Stephenson 2006-08-13 17:01 ` Nikolai Weibull 0 siblings, 1 reply; 16+ messages in thread From: Peter Stephenson @ 2006-08-13 16:34 UTC (permalink / raw) To: Zsh Users' List "Nikolai Weibull" wrote: > On 8/10/06, Peter Stephenson <p.w.stephenson@ntlworld.com> wrote: > > > zstyle ':completion:*' matcher-list 'm:{a-zA-Z}={A-Za-z}' 'r:|[.,_-]=**r:|= > **' > > What exactly are the 'r's doing here? That's become a bit garbled: the bit we're referring to should look like 'r:|[.,_-]=** r:|=**' There's a fairly full description of this in MATCHING CONTROL in the zshcompwid manual page---in something of the sense of "I couldn't walk across the English Channel because the sea was fairly full", so I'll summarise here. The general form is r:LPAT|RANCHOR=TPAT where LPAT has to occur on the left of the string already on the command line, RANCHOR indicates something at the right hand end of the string on the line, and TPAT says what sort of pattern to use to try to match the stuff in the middle when looking for possible completions. The LPAT isn't commonly used and if it's empty it has no particularly special meaning. The [.,_-] says look for any part of the code on the command line which has any of the those characters to the right. The ** then says match anything there; a single * wouldn't allow the anchor, i.e. the character out of that set in square brackets, to be matched itself, so you'd have to have typed any anchor characters yourself. The result is that something like u-l-o-h is matched as u*-l*-o*-h. (If we'd used r:|[.,_-]=* those *'s wouldn't have matched further -'s, as we've doubled the * they can.) The r:|=** matches at the end of the string: that's only necessary if you're completing in the middle and want to act as if there was a * there. In other words, without it, u-l-o<CURSOR>-h would have been treated as u*-l*-o*-h, with it it's treated as u*-l*-o*-h*. (This supposedly depends on COMPLETE_IN_WORD being set; if it isn't completion always takes place at the end.) Quite why this forces a distinction between script as an executablle and script as a directory is one of the great mysteries of the modern world. -- Peter Stephenson <p.w.stephenson@ntlworld.com> Web page now at http://homepage.ntlworld.com/p.w.stephenson/ ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: Completing a unique prefix of "script" completes "script" 2006-08-13 16:34 ` Peter Stephenson @ 2006-08-13 17:01 ` Nikolai Weibull 0 siblings, 0 replies; 16+ messages in thread From: Nikolai Weibull @ 2006-08-13 17:01 UTC (permalink / raw) To: Peter Stephenson; +Cc: Zsh Users' List On 8/13/06, Peter Stephenson <p.w.stephenson@ntlworld.com> wrote: > "Nikolai Weibull" wrote: > > On 8/10/06, Peter Stephenson <p.w.stephenson@ntlworld.com> wrote: > > > > > zstyle ':completion:*' matcher-list 'm:{a-zA-Z}={A-Za-z}' 'r:|[.,_-]=**r:|= > > **' > > > > What exactly are the 'r's doing here? > > That's become a bit garbled: the bit we're referring to should look like > > 'r:|[.,_-]=** r:|=**' That's what I figured. [excellent description of 'r' matcher-list operator] Thanks! > Quite why this forces a distinction between script as an executablle and > script as a directory is one of the great mysteries of the modern world. Hehe, it's bad when this comes from a lead developer... nikolai ^ permalink raw reply [flat|nested] 16+ messages in thread
* Problem with _arguments @ 2006-11-21 22:57 ` Nikolai Weibull 2006-11-21 23:42 ` Peter Stephenson 0 siblings, 1 reply; 16+ messages in thread From: Nikolai Weibull @ 2006-11-21 22:57 UTC (permalink / raw) To: zsh-users Say that I have #compdef craptastic _arguments \ '-s[omething]:with an argument' \ '*:directory:_directories' Then, at least with my setup, if I have the following command line and press <Tab> I get: % craptastic -s <Tab> ::: with an argument ::: but if I have the following and press <Tab> I get: % craptastic src -s <Tab> ::: with an argument ::: ::: directory ::: Why is directory all of a sudden a viable option here? It makes no sense. No banging my fists against my head has made me any wiser (and, believe you me, I've tried...repeatedly). a really f:ing pissed off nikolai ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: Problem with _arguments 2006-11-21 22:57 ` Problem with _arguments Nikolai Weibull @ 2006-11-21 23:42 ` Peter Stephenson 2006-11-22 8:35 ` Nikolai Weibull 0 siblings, 1 reply; 16+ messages in thread From: Peter Stephenson @ 2006-11-21 23:42 UTC (permalink / raw) To: zsh-users "Nikolai Weibull" wrote: > Say that I have > > #compdef craptastic > > _arguments \ > '-s[omething]:with an argument' \ > '*:directory:_directories' > > Then, at least with my setup, if I have the following command line and > press <Tab> I get: > > % craptastic -s <Tab> > ::: with an argument ::: > > but if I have the following and press <Tab> I get: > > % craptastic src -s <Tab> > ::: with an argument ::: > ::: directory ::: > > Why is directory all of a sudden a viable option here? _arguments [ -nswWACRS ] [ -O name ] [ -M matchspec ] [ : ] spec ... This function can be used to give a complete specification for completion for a command whose arguments follow standard UNIX option and argument conventions. "Standard UNIX option and argument conventions" are that all options come before all non-option arguments. The GNU extension that they can occur in any order is not supported. So -s is an argument following the argument src. _arguments thinks src, -s and the argument you're now completing are normal arguments and hence completes directories. Offers to add the option for the GNU extension as an option to _arguments to be applied if POSIXLY_CORRECT isn't set will be gladly accepted. Volunteer must like murky code with limited comments. The ability to spend hours puzzling over why individual lines are written the way they are would be an advantage. -- Peter Stephenson <p.w.stephenson@ntlworld.com> Web page now at http://homepage.ntlworld.com/p.w.stephenson/ ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: Problem with _arguments 2006-11-21 23:42 ` Peter Stephenson @ 2006-11-22 8:35 ` Nikolai Weibull 2006-11-22 10:39 ` Peter Stephenson 0 siblings, 1 reply; 16+ messages in thread From: Nikolai Weibull @ 2006-11-22 8:35 UTC (permalink / raw) To: Peter Stephenson; +Cc: zsh-users On 11/22/06, Peter Stephenson <p.w.stephenson@ntlworld.com> wrote: > "Nikolai Weibull" wrote: > > Say that I have > > > > #compdef craptastic > > > > _arguments \ > > '-s[omething]:with an argument' \ > > '*:directory:_directories' > > > > Then, at least with my setup, if I have the following command line and > > press <Tab> I get: > > > > % craptastic -s <Tab> > > ::: with an argument ::: > > > > but if I have the following and press <Tab> I get: > > > > % craptastic src -s <Tab> > > ::: with an argument ::: > > ::: directory ::: > > > > Why is directory all of a sudden a viable option here? > > _arguments [ -nswWACRS ] [ -O name ] [ -M matchspec ] [ : ] spec ... > This function can be used to give a complete specification for > completion for a command whose arguments follow standard UNIX > option and argument conventions. > > "Standard UNIX option and argument conventions" are that all options > come before all non-option arguments. The GNU extension that they can > occur in any order is not supported. So -s is an argument following the > argument src. _arguments thinks src, -s and the argument you're now > completing are normal arguments and hence completes directories. But it still offers the completion for -s, so it must have /some/ sort of understanding of what's going on already. Oh well, I guess I'll have to give up on this for the time being. Actually, would there be a good way of tricking _arguments into only seeing what you want it to see? In this case, it would work fine if one could trick it into only seeing the stuff after src, so that it would continue completing options. Thanks. nikolai ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: Problem with _arguments 2006-11-22 8:35 ` Nikolai Weibull @ 2006-11-22 10:39 ` Peter Stephenson 2006-11-22 15:55 ` Bart Schaefer 2006-11-22 21:31 ` Nikolai Weibull 0 siblings, 2 replies; 16+ messages in thread From: Peter Stephenson @ 2006-11-22 10:39 UTC (permalink / raw) To: zsh-users "Nikolai Weibull" wrote: > > > _arguments \ > > > '-s[omething]:with an argument' \ > > > '*:directory:_directories' > > > > > > % craptastic src -s <Tab> > > > ::: with an argument ::: > > > ::: directory ::: > > But it still offers the completion for -s, so it must have /some/ sort > of understanding of what's going on already. Right, my answer was a bit dozy... it looks like it's hedging, i.e. it's completing as if the strict POSIX and GNU forms are both allowed and it can't tell which applies. > Actually, would there be a good way of tricking _arguments into only > seeing what you want it to see? In this case, it would work fine if > one could trick it into only seeing the stuff after src, so that it > would continue completing options. There are certainly ways of updating the line, but the trouble is to find out what you need to do either you're going to be doing some parsing yourself or running _arguments twice. You can edit words (the command line) and CURRENT (the index into it), plus it's also possible in some contexts to tell _arguments to limit the words visible in the completion that it's calling by the use of enough colons. I find directly manipulating words and CURRENT less infuriating. -- Peter Stephenson <pws@csr.com> Software Engineer CSR PLC, Churchill House, Cambridge Business Park, Cowley Road Cambridge, CB4 0WZ, UK Tel: +44 (0)1223 692070 To access the latest news from CSR copy this link into a web browser: http://www.csr.com/email_sig.php ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: Problem with _arguments 2006-11-22 10:39 ` Peter Stephenson @ 2006-11-22 15:55 ` Bart Schaefer 2006-11-22 22:22 ` Nikolai Weibull 2006-11-22 21:31 ` Nikolai Weibull 1 sibling, 1 reply; 16+ messages in thread From: Bart Schaefer @ 2006-11-22 15:55 UTC (permalink / raw) To: zsh-users On Nov 22, 10:39am, Peter Stephenson wrote: } } parsing yourself or running _arguments twice. You can edit words (the } command line) and CURRENT (the index into it), plus it's also possible } in some contexts to tell _arguments to limit the words visible in the } completion that it's calling by the use of enough colons. I find } directly manipulating words and CURRENT less infuriating. Don't forget about compset: -n BEGIN [ END ] If the current word position as specified by the parameter CURRENT is greater than or equal to BEGIN, anything up to the BEGIN'th word is removed from the words array and the value of the parameter CURRENT is decremented by BEGIN. If the optional END is given, the modification is done only if the current word position is also less than or equal to END. In this case, the words from position END onwards are also removed from the words array. Both BEGIN and END may be negative to count backwards from the last element of the words array. -N BEG-PAT [ END-PAT ] If one of the elements of the words array before the one at the index given by the value of the parameter CURRENT matches the pattern BEG-PAT, all elements up to and including the matching one are removed from the words array and the value of CURRENT is changed to point to the same word in the changed array. If the optional pattern END-PAT is also given, and there is an element in the words array matching this pattern, the parameters are modified only if the index of this word is higher than the one given by the CURRENT parameter (so that the matching word has to be after the cursor). In this case, the words starting with the one matching end-pat are also removed from the words array. If words contains no word matching END-PAT, the testing and modification is performed as if it were not given. So it should work to do something like compset -N '[^-]*' before calling _arguments. ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: Problem with _arguments 2006-11-22 15:55 ` Bart Schaefer @ 2006-11-22 22:22 ` Nikolai Weibull 2006-11-24 20:56 ` Bart Schaefer 0 siblings, 1 reply; 16+ messages in thread From: Nikolai Weibull @ 2006-11-22 22:22 UTC (permalink / raw) To: Bart Schaefer; +Cc: zsh-users On 11/22/06, Bart Schaefer <schaefer@brasslantern.com> wrote: > On Nov 22, 10:39am, Peter Stephenson wrote: > } > } parsing yourself or running _arguments twice. You can edit words (the > } command line) and CURRENT (the index into it), plus it's also possible > } in some contexts to tell _arguments to limit the words visible in the > } completion that it's calling by the use of enough colons. I find > } directly manipulating words and CURRENT less infuriating. > > Don't forget about compset: > > -n BEGIN [ END ] > If the current word position as specified by the parameter > CURRENT is greater than or equal to BEGIN, anything up to the > BEGIN'th word is removed from the words array and the value > of the parameter CURRENT is decremented by BEGIN. > > If the optional END is given, the modification is done only if > the current word position is also less than or equal to END. > In this case, the words from position END onwards are also > removed from the words array. > > Both BEGIN and END may be negative to count backwards from > the last element of the words array. > > -N BEG-PAT [ END-PAT ] > If one of the elements of the words array before the one at > the index given by the value of the parameter CURRENT matches > the pattern BEG-PAT, all elements up to and including the > matching one are removed from the words array and the value > of CURRENT is changed to point to the same word in the > changed array. > > If the optional pattern END-PAT is also given, and there is an > element in the words array matching this pattern, the > parameters are modified only if the index of this word is > higher than the one given by the CURRENT parameter (so that > the matching word has to be after the cursor). In this case, > the words starting with the one matching end-pat are also > removed from the words array. If words contains no word > matching END-PAT, the testing and modification is performed > as if it were not given. > > So it should work to do something like > > compset -N '[^-]*' The problem with this is that it removes arguments to options, that is, it'll remove, as I understand it, the 1 to -maxdepth "find src -maxdepth 1" causing all sorts of confusion for the _arguments function and it won't complete anything after it any more. nikolai ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: Problem with _arguments 2006-11-22 22:22 ` Nikolai Weibull @ 2006-11-24 20:56 ` Bart Schaefer 0 siblings, 0 replies; 16+ messages in thread From: Bart Schaefer @ 2006-11-24 20:56 UTC (permalink / raw) To: zsh-users On Nov 22, 2:22pm, Nikolai Weibull wrote: } } > Don't forget about compset: } > } > -N BEG-PAT [ END-PAT ] } > If one of the elements of the words array before the one at } > the index given by the value of the parameter CURRENT matches } > the pattern BEG-PAT, all elements up to and including the } > matching one are removed from the words array ... } > } > If the optional pattern END-PAT is also given, and there is an } > element in the words array matching this pattern, the } > parameters are modified only if the index of this word is } > higher than the one given by the CURRENT parameter ... } > } > So it should work to do something like } > } > compset -N '[^-]*' } } The problem with this is that it removes arguments to options, that } is, it'll remove, as I understand it, the 1 to -maxdepth "find src } -maxdepth 1" causing all sorts of confusion for the _arguments } function and it won't complete anything after it any more. Actually in that case it should remove everything up to and including the "1" so the completion should behave as if there is nothing on the command line except the command word and the leading part of the word containing the cursor (assuming it is to the right of the "1") -- plus anything to the right of the cursor, of course. As your real usage is considerably more complex than the example you gave, that's probaby not what you want, but it's also not what you understood. ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: Problem with _arguments 2006-11-22 10:39 ` Peter Stephenson 2006-11-22 15:55 ` Bart Schaefer @ 2006-11-22 21:31 ` Nikolai Weibull 1 sibling, 0 replies; 16+ messages in thread From: Nikolai Weibull @ 2006-11-22 21:31 UTC (permalink / raw) To: Peter Stephenson; +Cc: zsh-users On 11/22/06, Peter Stephenson <pws@csr.com> wrote: > > Actually, would there be a good way of tricking _arguments into only > > seeing what you want it to see? In this case, it would work fine if > > one could trick it into only seeing the stuff after src, so that it > > would continue completing options. > > There are certainly ways of updating the line, but the trouble is to > find out what you need to do either you're going to be doing some > parsing yourself or running _arguments twice. You can edit words (the > command line) and CURRENT (the index into it), plus it's also possible > in some contexts to tell _arguments to limit the words visible in the > completion that it's calling by the use of enough colons. I find > directly manipulating words and CURRENT less infuriating. This worked out quite well actually. Find is actually incredibly complicated and has a rather horrible interface. Anyway, here's my solution: integer i (( i = index_of_find + 1 )) while [[ $words[i] == -([HLP]|-(help|version)) ]]; do (( i++ )) done while [[ -d $words[i] ]]; do (( i++ )) done words=($words[1,index_of_find] $words[i,-1]) (( CURRENT -= i - index_of_find - 1 )) integer old_words_length (( old_words_length = $#words )) words=(${words:#\\[()\!]}) (( CURRENT -= old_words_length - $#words )) Index_of_find keeps track of the index of -find in the words array. Here's the algorithm: 1. The option -find can be followed by the options -H, -L, or -P to specify how symbolic links are to be dealt with, along with -help or -version, so skip those. [1] 2. After that, any number of directories may follow. [2] 3. Now we know what slice to remove from the words array and we do so. 4. Next we need to remove any \!, any \(, and any \) that may appear in the $words array, as these are used to negate and group expressions and also mess up the command-line processing of _arguments. [3] /Now/ we can call _arguments. This can actually be used in _find as well, and I might submit a patch once I'm done with this completion definition (for mkisofs if that was unclear). Super-happy-fun-thank-yous to Peter and Bart for your suggestions on how to solve this. Your answers are always helpful, insightful, and to the point. Seriously, you guys rock. But it's also a bit sad that you seem to be the only two that posses the necessary knowledge of Zsh to answer these questions (and are active on these two mailing lists). I hope my shell-skills will reach your level some day. super-happy-fun-time-nikolai [1] Of course, if -help or -version is in the command line, completion has ended already (they're defined as '(- *)-help...' and '(- *)-version...'), so this is superfluous, but at least it's complete. [2] Checking that they're directories is also a bit stupid, and should perhaps only check that they don't match an option, for example, [^-]*, but I figured this was a bit more expressive. [3] This could technically be limited to only the slice [i,-1], but I wanted to keep things simple. ^ permalink raw reply [flat|nested] 16+ messages in thread
end of thread, other threads:[~2006-11-24 20:56 UTC | newest] Thread overview: 16+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- [not found] <now@bitwi.se> 2006-08-10 20:17 ` Completing a unique prefix of "script" completes "script" Nikolai Weibull 2006-08-10 21:41 ` Peter Stephenson 2006-08-13 14:49 ` Nikolai Weibull 2006-08-14 12:12 ` Peter Stephenson 2006-08-14 22:36 ` Nikolai Weibull 2006-08-13 14:59 ` Nikolai Weibull 2006-08-13 16:34 ` Peter Stephenson 2006-08-13 17:01 ` Nikolai Weibull 2006-11-21 22:57 ` Problem with _arguments Nikolai Weibull 2006-11-21 23:42 ` Peter Stephenson 2006-11-22 8:35 ` Nikolai Weibull 2006-11-22 10:39 ` Peter Stephenson 2006-11-22 15:55 ` Bart Schaefer 2006-11-22 22:22 ` Nikolai Weibull 2006-11-24 20:56 ` Bart Schaefer 2006-11-22 21:31 ` Nikolai Weibull
Code repositories for project(s) associated with this public inbox https://git.vuxu.org/mirror/zsh/ This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).