From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 6192 invoked from network); 18 Sep 2003 03:44:58 -0000 Received: from sunsite.dk (130.225.247.90) by ns1.primenet.com.au with SMTP; 18 Sep 2003 03:44:58 -0000 Received: (qmail 7192 invoked by alias); 18 Sep 2003 03:44:50 -0000 Mailing-List: contact zsh-workers-help@sunsite.dk; run by ezmlm Precedence: bulk X-No-Archive: yes X-Seq: 19099 Received: (qmail 7183 invoked from network); 18 Sep 2003 03:44:49 -0000 Received: from localhost (HELO sunsite.dk) (127.0.0.1) by localhost with SMTP; 18 Sep 2003 03:44:49 -0000 X-MessageWall-Score: 0 (sunsite.dk) Received: from [4.64.232.255] by sunsite.dk (MessageWall 1.0.8) with SMTP; 18 Sep 2003 3:44:48 -0000 Received: (from schaefer@localhost) by candle.brasslantern.com (8.11.6/8.11.6) id h8I3ilj06432 for zsh-workers@sunsite.dk; Wed, 17 Sep 2003 20:44:47 -0700 From: Bart Schaefer Message-Id: <1030918034447.ZM6431@candle.brasslantern.com> Date: Thu, 18 Sep 2003 03:44:47 +0000 In-Reply-To: <20030917193709.GA283@DervishD> Comments: In reply to DervishD "Re: Tags in function files" (Sep 17, 9:37pm) References: <20030916203559.GA2160@DervishD> <18188.1063784897@gmcs3.local> <20030917083752.GC4415@DervishD> <1030917163041.ZM5852@candle.brasslantern.com> <20030917193709.GA283@DervishD> X-Mailer: Z-Mail (5.0.0 30July97) To: Zsh Subject: Re: Tags in function files MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii [reordering things a little ...] On Sep 17, 9:37pm, DervishD wrote: > > My problem with the compsys documentation is that I don't know > which parameters, tags and the like are defined by compsys and which > ones are controled by Zsh guts ;)) I'm learning, slowly but surely ;) If it's in "man zshcompwid" (info doc, Completion Widgets section) then it's an internal parameter. If it's in "man zshcompsys" (Completion System section) then it's created by _main_complete or one of the helper functions it calls. Nearly all the parameters that you're supposed to access directly are internal; parameters of compsys are mostly "hidden" behind zstyles, or commands such as compdef. Conversely, all zstyles, tags, etc. are defined by compsys. There are no internally-defined tags. (There are several builtins to manipulate them [for speed], but you're not supposed to need to know that.) So if you're not using compinit, you can ignore anything that's said about styles and tags. > OK, now all makes sense. I was testing with a dummy widget (NOT a > completion one...) and I was able to use 'zle complete-word' inside > my widget, but I couldn't use '$words' (it expanded to nothing). On > the other hand, I created a dummy completion widget with zle -C but > then I wasn't able to use the predefined widgets inside. Right. ZLE is separate from the collection of completion modules. When a completion widget is invoked, zsh/zle gives control to zsh/complete, and won't accept control back again until the completion widget returns. Thus you can begin a completion from a normal widget, but you can't call back to a normal widget from a completion. (The normal widget can keep going after the completion finishes, but that's something different.) However, please note that there are no predefined completion widgets! There are only predefined completion _behaviors_ which happen to be described by a set of widget names. The competion widgets that _used_ to be predefined are now supplied by the zsh/compctl module, which has to be loaded in order for those widgets to do anything. As it turns out, if you attempt to use completion without first defining at least one widget, zsh automatically loads zsh/compctl just so that something sensible will happen. The illusion of predefined completion widgets is maintained, but it really is an illusion. > Namely something like this: > > my_comp () { > zle .complete-word > } > > zle -C dummycomp complete-word my_comp This sort of thing is why "compcall" (from the zsh/compctl module) is provided. You want: zmodload -i zsh/compctl my_comp () { compcall -D } The behavior of "compcall" is selected by the 2nd argument of "zle -C"; you can't switch from complete-word to expand-or-complete in midstream (except in so far as poking into the compstate parameter allows). > I would like to be able to last-resort to some > predefined completion widget, or even call some zle widget to move > the cursor, retrieve the story, clean the command line, etc... That > is, using some of the zle facilities inside my completion widget. Unfortunately you can't do the latter of those directly from within the completion widget. What you can do, I believe (having never tried it myself), is something like this: my_comp_wrapper () { local some_variable_set_by_my_comp_on_failure zle dummycomp # Invoke your completion, let it return if [[ -n $some_variable_set_by_my_comp_on_failure ]] then # move the cursor, retrieve the story, clean the command line fi } zle -N my_comp_wrapper bindkey '^O' my_comp_wrapper Just remember NOT to declare some_variable_set_by_my_comp_on_failure as a local in my_comp. You want it to modify its caller's local.