Zsh Mailing List Archive
Messages sorted by:
Reverse Date,
Date,
Thread,
Author
Re: [PATCH] Add API wrapper to ${+_comps[...]}
- X-seq: zsh-workers 36793
- From: Daniel Shahaf <d.s@xxxxxxxxxxxxxxxxxx>
- To: Bart Schaefer <schaefer@xxxxxxxxxxxxxxxx>
- Subject: Re: [PATCH] Add API wrapper to ${+_comps[...]}
- Date: Mon, 5 Oct 2015 22:33:02 +0000
- Cc: zsh-workers@xxxxxxx
- 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=
- In-reply-to: <151005151148.ZM4523@torch.brasslantern.com>
- List-help: <mailto:zsh-workers-help@zsh.org>
- List-id: Zsh Workers List <zsh-workers.zsh.org>
- List-post: <mailto:zsh-workers@zsh.org>
- Mailing-list: contact zsh-workers-help@xxxxxxx; run by ezmlm
- References: <20150930182948.GD2003@tarsus.local2> <151003174919.ZM31542@torch.brasslantern.com> <20151005215134.GA1959@tarsus.local2> <151005151148.ZM4523@torch.brasslantern.com>
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?
Messages sorted by:
Reverse Date,
Date,
Thread,
Author