From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 14199 invoked by alias); 3 May 2011 14:39:26 -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: 29139 Received: (qmail 16748 invoked from network); 3 May 2011 14:39:24 -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: <110503073902.ZM15889@torch.brasslantern.com> Date: Tue, 03 May 2011 07:39:00 -0700 In-reply-to: Comments: In reply to Felipe Contreras "Re: zle messes up 'words' variable?" (May 3, 11:05am) References: <110428203139.ZM11856@torch.brasslantern.com> <110502184235.ZM14465@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 3, 11:05am, Felipe Contreras wrote: } } The fact that it's documented as a special variable doesn't mean that } the behavior should be totally unexpected. } } 1) Without modifier } } Then 'words' can be re-used like any other variable. } } 2) With 'local' modifier } } Then modifying 'words' has an impact only on the current function, not } on the scope where the variable was defined as local. Ahh, I see the problem. You haven't read the entire documentation. At the very top of (what in the info file is) section 19.2 is this paragraph (caps mine for emphasis): Inside completion widgets, AND ANY FUNCTIONS CALLED FROM THEM, some parameters have special meaning; outside these functions they are not special to the shell in any way. These parameters are used to pass information between the completion code and the completion widget. Some of the builtin commands and the condition codes use or change the current values of these parameters. Any existing values will be hidden during execution of completion widgets; EXCEPT FOR COMPSTATE, THE PARAMETERS ARE RESET ON EACH FUNCTION EXIT (INCLUDING NESTED FUNCTION CALLS FROM WITHIN THE COMPLETION WIDGET) to the values they had when the function was entered. In other words, these variable are always local in all scopes, unless they are explicitly declared otherwise (which in this case requires the use of typeset -h). That's part of their special-ness, and is one of the things I assert is extremely unlikely to change. } 2.1) When using #compdef tag } } Then 'words' can be modified like any other variable. I thought you'd decided you were unable to reproduce this? If you now *are* able to reproduce it, then *that* might be a bug. } 3) With 'typedef -h' } } Then 'words' can be modified like any other variable. } } I was expecting an explanation of these discrepancies, and a way to } globally make 'words' work as expected without having to replace each } use of 'local' by 'typedef -h'. I apologize for not understanding the source of the mis-understanding. I was focusing on why #compdef might make a difference, not on the details of the actual scoping problem you perceived. } > 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. } } You are not good at compartmentalizing aren't you? I'm really disappointed in the way that mailing list discourse in general lately (and not just on this list) tends to rapidly descend into insults and ad-hominem attacks. I've been watching the CentOS list collapse under the weight of this sort of thing and I plead that we try to avoid it here. } If you fix the issue with my example, you fix the issue with } bashcompinit. It's the same issue. Or "riddle" if that word makes you } more comfortable. No, it's not the same issue, because bashcompinit has responsibility for loading the bash completion functions in a way that makes them compatible. That's not the same as first loading bashcompinit and then independently defining a new completion, though I lean toward the conclusion that use of the bash-compatible "complete" command is probably the correct place to fix this if it can be managed. --