From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 1567 invoked from network); 15 Mar 1999 16:35:10 -0000 Received: from sunsite.auc.dk (130.225.51.30) by ns1.primenet.com.au with SMTP; 15 Mar 1999 16:35:10 -0000 Received: (qmail 15395 invoked by alias); 15 Mar 1999 16:34:48 -0000 Mailing-List: contact zsh-workers-help@sunsite.auc.dk; run by ezmlm Precedence: bulk X-No-Archive: yes X-Seq: 5819 Received: (qmail 15388 invoked from network); 15 Mar 1999 16:34:46 -0000 Message-Id: <9903151618.AA36652@ibmth.df.unipi.it> To: zsh-workers@sunsite.auc.dk Subject: Re: -subscript- completion for assoc array In-Reply-To: "Sven Wischnowsky"'s message of "Mon, 15 Mar 1999 17:00:14 NFT." <199903151600.RAA23501@beta.informatik.hu-berlin.de> Date: Mon, 15 Mar 1999 17:18:38 +0100 From: Peter Stephenson Sven Wischnowsky wrote: > The problem with the missing `-' is not handled, but I found the > reason for it (and am not sure how we should change it). The reason is > that inside subscripts, match-mode parsing is done to get the string > to complete, which normally is a string of characters on which > `iident(c)' yields true. This is what one wants in math envs including > normal subscripts. Hm, I have to leave now so I won't be able to send > a patch for this now (hance this mail). I'll think some more about > this, but if some of you have ideas, let me know. > Possibilities include: give the whole subscript string to the function > (which is a bit ugly for normal subscripts), and let the C-code find > out what kind of parameter we have -- and let it report a new context > for assocs. I wouldn't have thought it would be too hard just to pass the whole string to the -subscript- handler, and inside that, if the parameter is not an assoc, simply IPREFIXify anything which is not alphanumeric before handing the rest on to the -math- handler. You don't even need special handling for variables with funny names, since they're always a single character so can't be completed further. Unless I've missed something. You could even argue that the -math- handler could be made responsible for deciding what to complete and what to IPREFIXify in every case. After thinking about it, I like this better, since it keeps string handling consistent within math-like contexts. It also allows you to have completion for the whole expression. For example, you could arrange for (( # -> selection of parameters as usual (( foo # -> matches "[a-z] *", cycle through selection # of operators (( foo + # -> it's a +, generate my own special # list of numbers to add to: 3.14159, 42, # 1000009, ... I'm not suggesting it's actually worth writing a function which does any of that apart from the first bit, even I can type `++' without feeling the need to hit TAB, but simply that it increases flexibility and decreases special-casing in the C code if this is transferred to the shell function. (Except, of course, when calling old completion, in which case you've got to do as much as is reasonable in C.) By the way, it's a bit annoying that the command is called `compdef' while the lines at the tops of the functions to do the same thing automatically are still `defcomp' etc. If it's not yet too late, it might be a good idea to change these to `compdef', `compdefpat' and `compdefkey'. -- Peter Stephenson Tel: +39 050 844536 WWW: http://www.ifh.de/~pws/ Dipartimento di Fisica, Via Buonarroti 2, 56127 Pisa, Italy