From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 4618 invoked from network); 7 Jun 2006 10:48:54 -0000 X-Spam-Checker-Version: SpamAssassin 3.1.3 (2006-06-01) on f.primenet.com.au X-Spam-Level: X-Spam-Status: No, score=-2.4 required=5.0 tests=AWL,BAYES_00, FORGED_RCVD_HELO autolearn=ham version=3.1.3 Received: from news.dotsrc.org (HELO a.mx.sunsite.dk) (130.225.247.88) by ns1.primenet.com.au with SMTP; 7 Jun 2006 10:48:54 -0000 Received: (qmail 80377 invoked from network); 7 Jun 2006 10:48:48 -0000 Received: from sunsite.dk (130.225.247.90) by a.mx.sunsite.dk with SMTP; 7 Jun 2006 10:48:48 -0000 Received: (qmail 7069 invoked by alias); 7 Jun 2006 10:48:39 -0000 Mailing-List: contact zsh-users-help@sunsite.dk; run by ezmlm Precedence: bulk X-No-Archive: yes X-Seq: 10356 Received: (qmail 7060 invoked from network); 7 Jun 2006 10:48:39 -0000 Received: from news.dotsrc.org (HELO a.mx.sunsite.dk) (130.225.247.88) by sunsite.dk with SMTP; 7 Jun 2006 10:48:39 -0000 Received: (qmail 79249 invoked from network); 7 Jun 2006 10:48:39 -0000 Received: from cluster-c.mailcontrol.com (168.143.177.190) by a.mx.sunsite.dk with SMTP; 7 Jun 2006 10:48:37 -0000 Received: from exchange03.csr.com (uuk202166.uk.customer.alter.net [62.189.241.194] (may be forged)) by rly23c.srv.mailcontrol.com (MailControl) with ESMTP id k57AhiY7020243 for ; Wed, 7 Jun 2006 11:48:33 +0100 Received: from cameurexb01.EUROPE.ROOT.PRI ([10.100.137.61]) by exchange03.csr.com with Microsoft SMTPSVC(5.0.2195.6713); Wed, 7 Jun 2006 11:47:46 +0100 Received: from news01.csr.com ([10.103.143.38]) by cameurexb01.EUROPE.ROOT.PRI with Microsoft SMTPSVC(6.0.3790.1830); Wed, 7 Jun 2006 11:47:21 +0100 Received: from news01.csr.com (localhost.localdomain [127.0.0.1]) by news01.csr.com (8.13.4/8.13.4) with ESMTP id k57AljZi028430 for ; Wed, 7 Jun 2006 11:47:45 +0100 Received: from csr.com (pws@localhost) by news01.csr.com (8.13.4/8.13.4/Submit) with ESMTP id k57AljuP028426 for ; Wed, 7 Jun 2006 11:47:45 +0100 Message-Id: <200606071047.k57AljuP028426@news01.csr.com> X-Authentication-Warning: news01.csr.com: pws owned process doing -bs To: zsh-users@sunsite.dk Subject: Re: java class names completion widget In-reply-to: <200606052240.27880.kos@supportwizard.com> References: <200606052240.27880.kos@supportwizard.com> Comments: In-reply-to Konstantin Sobolev message dated "Mon, 05 Jun 2006 22:40:27 +0400." Date: Wed, 07 Jun 2006 11:47:45 +0100 From: Peter Stephenson X-OriginalArrivalTime: 07 Jun 2006 10:47:21.0512 (UTC) FILETIME=[C11C6280:01C68A1F] Content-Type: text/plain MIME-Version: 1.0 X-Scanned-By: MailControl A-07-00-10 (www.mailcontrol.com) on 10.67.0.133 Konstantin Sobolev wrote: > kos@kos ~/work/jrs/src $ fcl SHMa > ./org/kos/jrs/SoftHashMap.java > > Now I want to convert it into a completion widget. What is the easiest way to > do it? (I'm going to assume you're already using the new completion system, which seems to be the case.) You can actually do the case matching element within zsh without any new code; the difficult bit is the combination of completion and finding files, but that's difficult to hook in to completion regardless of whether the expansion is done inside or outside the shell. Here's how you do the basic completion (given the problems this probably isn't what you want, so I'll look at another method later). The following adds the smash case completion to the context after javac: zstyle ':completion:*:javac:*' matcher 'r:|[A-Z]=* r:|=*' This means roughly "allow all capital letters on the command line to be followed immediately on the right by any pattern in trial completions, and allow the end of the string on the command line to be followed by any pattern in trial completions". More complicated variants are possible and are described for this very case in the zshcompwid manual page (under MATCHING CONTROL). You can also change the context where this is applied; this is described under COMPLETION SYSTEM CONFIGURATION in the zshcompsys manual page. This allows "javac SHMa" to complete to "javac SoftHashMap.java", but it doesn't handle path searching. You can, however, do javac ./o/k/j/SHMa since path elements are completed, but you can't do a general search that I know of. So let's concentrate on the search element. This is more difficult, because zsh usually separates expansion and completion. So if you have the _expand completer in use, javac **/*.java would expand to all .java files in subdirectories, but javac **/SHMa wouldn't do anything, because the matching control isn't applied to expansions. So instead let's hijack the _expand completer and provide a front end. The trouble with making this the normal contextual completer in place of _java is that you'll lose all the features of that and need to merge together what you want. Hence what I suggest you do is use a separate completion when you want the special behaviour. Then you'll have to remember to type a different key sequence for this, say C-x j. Here's the full code; put it in a file (say _expand_java_path) in your function path: #compdef -k complete-word ^xj local MATCH MBEGIN MEND # Turn the start of the string on the line into **/ followed # by the original prefix with upper case letters followed # by [^[:upper:]]# which matches any number of consecutive # non-upper-case characters. This relies on the fact that # the completion system uses the EXTENDED_GLOB option. PREFIX="**/${PREFIX//(#m)[[:upper:]]/${MATCH}[^[:upper:]]#}" # Replace the end of the string similarly, adding *.java to # the pattern SUFFIX="${SUFFIX//(#m)[[:upper:]]/${MATCH}[^[:upper:]]#}*.java" # Now we've got a zsh recursive matching pattern; for example # SHMa # has turned into # **/S[^[:upper:]]#H[^[:upper:]]#M[^[:upper:]]#a*.java # Let the normal _expand completer get to work. _expand "$@" (Four lines of active code for the whole thing!) Those are the basics; there are many, many possible bells and whistles since all the features of the completion system are available for offering you matches, and actually the _expand completer does a bit to much work for us; we just want the globbing effect. In particular, the behaviour with ambiguous expansions could be better configured. _expand turns on menu completion when inserting. Currently it will cycle through possible expansions, then all expansions, then the original pattern (though it's not the original, it's the hacked version from _expand_java_path so isn't much use). You can use the tag-order style to help. -- Peter Stephenson 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