From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 23973 invoked from network); 30 Mar 2001 09:16:48 -0000 Received: from sunsite.dk (130.225.51.30) by ns1.primenet.com.au with SMTP; 30 Mar 2001 09:16:48 -0000 Received: (qmail 25085 invoked by alias); 30 Mar 2001 09:16:41 -0000 Mailing-List: contact zsh-workers-help@sunsite.dk; run by ezmlm Precedence: bulk X-No-Archive: yes X-Seq: 13850 Received: (qmail 25073 invoked from network); 30 Mar 2001 09:16:40 -0000 Message-ID: <20010330091639.88862.qmail@web9305.mail.yahoo.com> Date: Fri, 30 Mar 2001 10:16:39 +0100 (BST) From: =?iso-8859-1?q?Oliver=20Kiddle?= Subject: Re: Two missing completion functions that bug me To: zsh-workers@sunsite.dk In-Reply-To: <1010329162403.ZM19148@candle.brasslantern.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit --- Bart Schaefer wrote: > You're right; upon another attempt, none of -c, -e, nor -h need the > `+'. The plus says that the argument to the option can appear in the same or subsequent word. I used it for only -p and -r. The -s passed to _arguments allowed options to be in one word. > but in fact that's because -a takes an argument, not (only) because Actually, the way I had written this was to not specify that -a or -A took an argument because they don't really. The manual shows: vared [-Aache] [-p prompt] [-r rprompt] name I interpret this as meaning that -A and -a do not take an argument. What they do is modify the type of the final argument (name). For -a/-A, my function had just: '(-a)-A[create an associative array]' \ '(-A)-a[create an array]' \ and I finished it with: '1:parameter:_vars' # Note also, I used a 1 which you didn't # - can only vared one parameter so with -A or -a, mine wasn't going to limit completion to arrays. It didn't really occur to be to use _parameters -g for them. The solution would be to use a state for the last (parameter) argument and make it check $opt_args and select either _vars or _parameters depending on this. I'm not sure whether it is worth it to do this because -A and -a are only of any use if combined with -c so when creating a new array which won't exist to be completed anyway. > } Would it be worth it to try to have completions for all builtins > ready > } for 4.0? > Possibly. I looked at a few yesterday and didn't get very far because it doesn't make sense for many. I've got a few queries and thoughts: I got confused as to why the r variant of fc allows -l. I thought it would just use _command_names (and history numbers which we don't have a function for). I only use zle based and csh style history so don't know much about the ksh stuff. What should it take? Are getln and pushln of any use interactively? I got confused trying to alter _read and _print for them. _ttyctl was a 5 second job so is done. (commit after Sven's great move) pwd and echo would be fairly doable if we ignore the possibility of someone disabling them or using /bin/pwd. Do any non-builtin pwd's take any arguments? Any ideas on the types of echo? We really need the generalised _is_gnu for this. : by definition should use default completion so I'll leave it. Is it worth doing one for test / [. It is tempting to define one to: _message 'use conditional expressions (with [[ ... ]]) instead' > I get the same list as you, by comparing ${(k)_comps} to > ${(k)builtins}. Exactly what I did. I've got a static zsh without many modules here though and there will be a few builtins which use something standard like _parameters. > compadd compdescribe compgroups compset comptry > comparguments compfiles compquote comptags > compvalues True. There is your your point about interactive function writing though. I also sometimes use zsh completion as a quicker alternatve to man pages. Would anyone find any of these useful? I'm quite tempted to write one for compadd. > Similarly zregexparse, which although it could be used interactively, Yes, I've never used that. I'm not even sure how many people other than Akira and Sven have even looked at _regex_arguments. I only fairly recently had a serious look at it and there were still quite a few typos in the documentation (which I fixed) which just goes to show how few people have looked at it. > These don't need completions because they're keywords: > break continue so is nocorrect which does have a completion. Arguably, the completion system should handle it elsewhere like it does with, for example while. > Which leaves: > > : echo pushln suspend umask > [ exit pwd test zformat > bye getln r ttyctl zparseopts > dirs logout return ulimit zprof bye, exit and return could maybe share a functon which just calls message with something like 'return code'. ulimit could/should have a completion written. I've always used limit being a tcsh convert but I'll look into this. umask is fairly easy (but not very useful) so I'll do it. This reminds me: ages ago I thought of doing an intelligent completion for chmod so for example, chmod g+x would only complete files lacking group execute permission. > } Any ideas what should be done for commands with just one option > } (like suspend) - completing -f might not be what people expect. > > Behave as if prefix-needed is true. Complete nothing unless the `-' > is > already there. I was also wondering if it should maybe list the single -f option with a description rather than completing it so you can see what it does. Oliver ____________________________________________________________ Do You Yahoo!? Get your free @yahoo.co.uk address at http://mail.yahoo.co.uk or your free @yahoo.ie address at http://mail.yahoo.ie