From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 20375 invoked from network); 23 Mar 1999 14:07:35 -0000 Received: from sunsite.auc.dk (130.225.51.30) by ns1.primenet.com.au with SMTP; 23 Mar 1999 14:07:35 -0000 Received: (qmail 27131 invoked by alias); 23 Mar 1999 14:00:35 -0000 Mailing-List: contact zsh-workers-help@sunsite.auc.dk; run by ezmlm Precedence: bulk X-No-Archive: yes X-Seq: 5902 Received: (qmail 27123 invoked from network); 23 Mar 1999 14:00:33 -0000 Date: Tue, 23 Mar 1999 14:59:13 +0100 (MET) Message-Id: <199903231359.OAA19227@beta.informatik.hu-berlin.de> From: Sven Wischnowsky To: zsh-workers@sunsite.auc.dk In-reply-to: "Andrej Borsenkow"'s message of Tue, 23 Mar 1999 16:42:20 +0300 Subject: Re: Fun with new completion Andrej Borsenkow wrote: > bor@itsrm2:~%> vared pat > pat path > > In other words, vared tried to complete the name of local variable, that is > defined in completion function :-) pat is not defined otherwise. > > And it just occured to me, that the same could happen in e.g. [un]setopt. As > I understand, they do it by listing currently set/unset options ... with the > result, that if options are changed in some top level function, they will > list wrong options ... I was aware of the problem with parameter names, but hadn't thought about the options. Maybe we should rename the local parameters (where needed) to `_...', modify the function `_vars' to show only parameters without a leading underscore and be callable from everywhere. For the options I can only see the solution to make `_main_complete' save the original set and unset options in arrays and then add two functions to complete from these arrays (this is currently only used for `setopt' and `unsetopt', but to make this cleanly...). Bye Sven -- Sven Wischnowsky wischnow@informatik.hu-berlin.de