From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 26553 invoked from network); 8 Apr 2009 16:03:43 -0000 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on f.primenet.com.au X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.2.5 Received: from news.dotsrc.org (HELO a.mx.sunsite.dk) (130.225.247.88) by ns1.primenet.com.au with SMTP; 8 Apr 2009 16:03:43 -0000 Received-SPF: none (ns1.primenet.com.au: domain at sunsite.dk does not designate permitted sender hosts) Received: (qmail 28843 invoked from network); 8 Apr 2009 16:03:36 -0000 Received: from sunsite.dk (130.225.247.90) by a.mx.sunsite.dk with SMTP; 8 Apr 2009 16:03:36 -0000 Received: (qmail 26512 invoked by alias); 8 Apr 2009 16:03:30 -0000 Mailing-List: contact zsh-workers-help@sunsite.dk; run by ezmlm Precedence: bulk X-No-Archive: yes X-Seq: 26826 Received: (qmail 26496 invoked from network); 8 Apr 2009 16:03:29 -0000 Received: from bifrost.dotsrc.org (130.225.254.106) by sunsite.dk with SMTP; 8 Apr 2009 16:03:29 -0000 Received: from vms173007pub.verizon.net (vms173007pub.verizon.net [206.46.173.7]) by bifrost.dotsrc.org (Postfix) with ESMTP id 1E35782D4B6F for ; Wed, 8 Apr 2009 18:03:23 +0200 (CEST) Received: from torch.brasslantern.com ([96.249.201.13]) by vms173007.mailsrvcs.net (Sun Java(tm) System Messaging Server 6.3-7.04 (built Sep 26 2008; 32bit)) with ESMTPA id <0KHS00J7JHWVWS9W@vms173007.mailsrvcs.net> for zsh-workers@sunsite.dk; Wed, 08 Apr 2009 11:03:00 -0500 (CDT) Received: from torch.brasslantern.com (localhost.localdomain [127.0.0.1]) by torch.brasslantern.com (8.13.1/8.13.1) with ESMTP id n38G2saJ021248 for ; Wed, 08 Apr 2009 09:02:55 -0700 Received: (from schaefer@localhost) by torch.brasslantern.com (8.13.1/8.13.1/Submit) id n38G2rUh021247 for zsh-workers@sunsite.dk; Wed, 08 Apr 2009 09:02:53 -0700 From: Bart Schaefer Message-id: <090408090253.ZM21246@torch.brasslantern.com> Date: Wed, 08 Apr 2009 09:02:53 -0700 In-reply-to: <20090408044920.GA21100@datura.dylex.net> Comments: In reply to Dylan Alex Simon "crash when expand-or-complete widget wrapped" (Apr 8, 12:49am) References: <20090407035737.GA4200@datura.dylex.net> <20090408044920.GA21100@datura.dylex.net> X-Mailer: OpenZMail Classic (0.9.2 24April2005) To: zsh-workers@sunsite.dk Subject: Re: crash when expand-or-complete widget wrapped MIME-version: 1.0 Content-type: text/plain; charset=us-ascii X-Virus-Scanned: ClamAV 0.92.1/9213/Wed Apr 8 14:41:44 2009 on bifrost X-Virus-Status: Clean On Apr 8, 12:49am, Dylan Alex Simon wrote: } } > > Try the patch below. Doesn't actually find any useful completions, } > > but at least fixes the infinite-but-for-memory-limits loop. } > } > Yes, that's correct, it was just a typo I introduced recently before } > 4.3.9. } } Is there some reason this is not an okay thing to do or that } completion widgets should be called differently? (I'm working on } improving predict-on.) It shouldn't outright crash, but ... You can't call completion widgets from non-completion widgets, in the general case. In fact you generally can't call completion widgets with "zle widget_name", because completion widgets don't share the normal editor state. Instead you need to create your wrapper widget as a completion widget itself, and then call the function that implements the other widget directly, such as: widget-wrapper () { $WIDGET "$@" } zle -C widget-wrapper expand-or-complete widget-wrapper See the implementations of _complete_help or _complete_debug for examples, note that they set things up and then call _main_complete directly. Yes, this means there is no way to "wrap" a built-in completion widget. I think you can call completion widgets from normal widgets by pushing keystrokes with "zle -U" and then invoking "zle recursive-edit" but I'm not entirely sure it will always work.