From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 26042 invoked by alias); 5 Oct 2015 22:33:07 -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: 36793 Received: (qmail 22283 invoked from network); 5 Oct 2015 22:33:06 -0000 X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on f.primenet.com.au X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,T_DKIM_INVALID autolearn=ham autolearn_force=no version=3.4.0 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= daniel.shahaf.name; h=cc:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-sasl-enc :x-sasl-enc; s=mesmtp; bh=cEiyALhEF/1nMmDHjUm/dR2wUfc=; b=UZvfDV ZLi2dEGe4J+oO3RienGmPkQ97gMlfTBdEy2Zwy5tq/K0NCc5b0FGff3jh7ELsl+a nP18MbmKzDng+F+1075xlJYScFsJyYy0u7c6QqQOOSYLseOdt4Q4/04VPR4Bt3Wn QH6SNl3oSYPVLyps9g/o6C1cGO8cHdX/Ql+kk= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-sasl-enc :x-sasl-enc; s=smtpout; bh=cEiyALhEF/1nMmDHjUm/dR2wUfc=; b=WT+ww KExfnzCEG4LM17dHIW9xE7VeKJ8BIWolVpJwhrs6GDvLVgfiwVClit1bzSvlIXDv MO+9Au5Ocu5GUgRPrp8ss3Zkot+bNRAz2MEN9WjFVKW8lpM5jGLYse95wJq023Ar 14Lbjze8M2idm2KCj7t5Jyf1KwnKabmXEnDInE= X-Sasl-enc: siHx1rt8IHdxg4RUV5WE8o1UZ2NIrwaOP+q7hnikofWy 1444084384 Date: Mon, 5 Oct 2015 22:33:02 +0000 From: Daniel Shahaf To: Bart Schaefer Cc: zsh-workers@zsh.org Subject: Re: [PATCH] Add API wrapper to ${+_comps[...]} Message-ID: <20151005223302.GD2367@tarsus.local2> References: <20150930182948.GD2003@tarsus.local2> <151003174919.ZM31542@torch.brasslantern.com> <20151005215134.GA1959@tarsus.local2> <151005151148.ZM4523@torch.brasslantern.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <151005151148.ZM4523@torch.brasslantern.com> User-Agent: Mutt/1.5.21 (2010-09-15) Bart Schaefer wrote on Mon, Oct 05, 2015 at 15:11:48 -0700: > On Oct 5, 9:51pm, Daniel Shahaf wrote: > } Subject: Re: [PATCH] Add API wrapper to ${+_comps[...]} > } > } Bart Schaefer wrote on Sat, Oct 03, 2015 at 17:49:19 -0700: > } > > } > (Why two separate patches both to compsys.yo?) > } > } One logical change per commit. > > But you don't care about one logical commit per zsh-workers sequence > number? I mean, I'm not unreasonably sticky about it, but I try to > keep it that way. > How would I handle a case such as 36725 (three patches to a single module)? I know some people handle this with git-send-email, but I don't have that set up. Would it help to write the commit messages and changelog entries as 36725/0001, 36725/0002, etc, where the running counter is the first part of the filename? (which is generated by 'git format-patch') > } > On the other hand there are tests for whether a particular function > } > is defined. If that function is destined to be assigned to _comps[x] > } > perhaps it would be better to check for _comps[x] already defined > } > instead. > } > } _comps[x] being already defined in what sense? I can think of three > } meanings: (a) hash key exists > > That sense. > > The point being that if we're going to bother defining "compexists" > then maybe we ought to use it instead of (( ${+functions[_name]} )). > It couldn't replace all such tests, since in most cases those are > "helper" functions rather than values in $_comps, but perhaps some. > It seems most cases are of the "allow an helper function to be overridden" variety. The usage in _calendar:3 is an exception, but couldn't benefit from compexists. > I'm trying to find a metric for usefulness. The difference between f() { [[ $# == 1 ]] || return 2 (( $+_comps[$1] )) } and g() { [[ $# == 1 ]] || return 2 (( $+_comps[$1] )) && (( $+functions[$_comps[$1]] )) } is how they handle the case 'compdef _foo foo' with _foo() not having being defined yet (nor marked for autoload). Is this a common case? When does it happen?