From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 29750 invoked by alias); 3 May 2011 01:42:54 -0000 Mailing-List: contact zsh-workers-help@zsh.org; run by ezmlm Precedence: bulk X-No-Archive: yes List-Id: Zsh Workers List List-Post: List-Help: X-Seq: 29131 Received: (qmail 12542 invoked from network); 3 May 2011 01:42:51 -0000 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on f.primenet.com.au X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_NONE autolearn=ham version=3.3.1 Received-SPF: none (ns1.primenet.com.au: domain at closedmail.com does not designate permitted sender hosts) From: Bart Schaefer Message-id: <110502184235.ZM14465@torch.brasslantern.com> Date: Mon, 02 May 2011 18:42:35 -0700 In-reply-to: Comments: In reply to Felipe Contreras "Re: zle messes up 'words' variable?" (May 2, 9:11pm) References: <110428203139.ZM11856@torch.brasslantern.com> X-Mailer: OpenZMail Classic (0.9.2 24April2005) To: Felipe Contreras Subject: Re: zle messes up 'words' variable? Cc: zsh-workers@zsh.org MIME-version: 1.0 Content-type: text/plain; charset=us-ascii On May 2, 9:11pm, Felipe Contreras wrote: } } On Fri, Apr 29, 2011 at 6:31 AM, Bart Schaefer } wrote: } > Your example in workers/29086 explicitly loads and runs bashcompinit. } > What am I missing? } } What is 'workers/29086'? Sorry, I'm writing in zsh-workers subscriber-speke. Every message sent to the zsh-workers (or zsh-users) list is tagged with an "X-Seq:" header containing a number. The archive server at zsh.org is able to look up messages by sequence number. So we shorthand "go to the zsh.org archive and put 29086 into the workers lookup field" as "workers/29086". } I am using bashcompinit, but the issue appears without it. Without bashcompinit, there is by definition not an issue. Or, if you prefer, you should have expected this issue to appear, because words is documented as a special variable in completion function context. If what you want to discuss is ways to fix bashcompinit so that the functions in bash completion work as expected, that's one thing. If what you're asking is for the special-ness of "words" to be undone for completion in general, that's so unlikely to happen as to not be worth continuing.