From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 23936 invoked from network); 12 Apr 2009 17:56:06 -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; 12 Apr 2009 17:56:06 -0000 Received-SPF: none (ns1.primenet.com.au: domain at sunsite.dk does not designate permitted sender hosts) Received: (qmail 39333 invoked from network); 12 Apr 2009 17:56:00 -0000 Received: from sunsite.dk (130.225.247.90) by a.mx.sunsite.dk with SMTP; 12 Apr 2009 17:56:00 -0000 Received: (qmail 27173 invoked by alias); 12 Apr 2009 17:55:53 -0000 Mailing-List: contact zsh-workers-help@sunsite.dk; run by ezmlm Precedence: bulk X-No-Archive: yes X-Seq: 26832 Received: (qmail 27153 invoked from network); 12 Apr 2009 17:55:53 -0000 Received: from bifrost.dotsrc.org (130.225.254.106) by sunsite.dk with SMTP; 12 Apr 2009 17:55:53 -0000 Received: from vms173005pub.verizon.net (vms173005pub.verizon.net [206.46.173.5]) by bifrost.dotsrc.org (Postfix) with ESMTP id EED748058ACF for ; Sun, 12 Apr 2009 19:55:47 +0200 (CEST) Received: from torch.brasslantern.com ([96.249.201.13]) by vms173005.mailsrvcs.net (Sun Java(tm) System Messaging Server 6.3-7.04 (built Sep 26 2008; 32bit)) with ESMTPA id <0KI0002SK1SUCGPQ@vms173005.mailsrvcs.net> for zsh-workers@sunsite.dk; Sun, 12 Apr 2009 12:55:43 -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 n3CHtfPZ020040 for ; Sun, 12 Apr 2009 10:55:41 -0700 Received: (from schaefer@localhost) by torch.brasslantern.com (8.13.1/8.13.1/Submit) id n3CHte3P020039 for zsh-workers@sunsite.dk; Sun, 12 Apr 2009 10:55:40 -0700 From: Bart Schaefer Message-id: <090412105540.ZM20038@torch.brasslantern.com> Date: Sun, 12 Apr 2009 10:55:40 -0700 In-reply-to: <20090411043152.GA26742@datura.dylex.net> Comments: In reply to Dylan Alex Simon "Re: crash when expand-or-complete widget wrapped" (Apr 11, 12:31am) References: <20090407035737.GA4200@datura.dylex.net> <20090408044920.GA21100@datura.dylex.net> <20090411043152.GA26742@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/9225/Sun Apr 12 05:35:10 2009 on bifrost X-Virus-Status: Clean On Apr 11, 12:31am, Dylan Alex Simon wrote: } Subject: Re: crash when expand-or-complete widget wrapped } } > > 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.) } > } > 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. } } > zle -C widget-wrapper expand-or-complete widget-wrapper } } Sorry, I guess my question was a little confused (I shouldn't have } said "completion widgets"). As far as I understand, expand-or-complete } and complete-word are not themselves actual completion widgets (they } aren't generating completion lists) but rather zle widgets that invoke } completion. No, you spoke correctly: "completion widgets" are zle widgets (either built-in or user-defined) to invoke completion; "completion functions" are shell functions intended to be bound to completion widgets with "zle -C"; and "completers" are shell functions that generate matches for use by completion functions. However, those terms are not always used with very much precision. Also, "completion system" refers to the entire set of completers and completion functions as installed by "compinit" (and thereby turned into completion widgets). What's confused is my memory. It should be OK to invoke a completion widget from a normal widget; what doesn't work is invoking a normal widget from a completion function (or from a completer). } The problem seems only to happen when you invoke the dotted version } "zle .expand-or-complete" rather than "zle expand-and-complete". I'm unable to reproduce the crash, but I believe I know at least part of what's going on here. "compinit" replaces the built-in complete-word, expand-or-complete, etc., widgets with the completion function bindings that call through to _main_complete to invoke the completion system. However, one of the basic rules of zle widgets is that the dotted versions are immutable, so compinit can't replace those. When you define your widget-wrapper to invoke "zle .$WIDGET", you're calling directly through to the built-in widgets, bypassing the completion system entirely and calling into the old compctl system. Those "old" widgets nevertheless share some guts with the builtins that form the core of the "new" completion system, and I suspect that there's an unexpected conflict caused by insert-and-predict playing with BUFFER and/or CURSOR and/or the values in the compstate hash.