Zsh Mailing List Archive
Messages sorted by:
Re: plugin conventions (Re: off topic)
- X-seq: zsh-workers 40192
- From: Bart Schaefer <schaefer@xxxxxxxxxxxxxxxx>
- To: zsh-workers@xxxxxxx
- Subject: Re: plugin conventions (Re: off topic)
- Date: Wed, 14 Dec 2016 15:51:26 -0800
- Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=brasslantern-com.20150623.gappssmtp.com; s=20150623; h=from:message-id:date:in-reply-to:comments:references:to:subject :mime-version; bh=+TLKkrjPcYmJpxkHQtebeXl0OyYOSHGMxHM86FWJopo=; b=Tu8IHhtC/oD0ToUSx/zuqOBmxweS2s83mbP3OTVlmNWfHfE21cwp/zYI/XGOOsipcp 6JmaoPDO1qXmhzgnh1nELbWm2zt1ViSjtLPpIVO87oAsCptVhWNAC6ZjbtvNqit8hNWk Hz8r9QtdYWECdCVxRjUy+xseIzhb+NsNUVZS70WASHkJKh+exM5Wc2lGBNaEs6Z0yq7r yPrl7euxvBovLis48UNgK3S5lHiqllAecGCiyYhJqszG1pbE4HIuCV/cPQRFyCKzlAc9 uy5tNxIMmcDiflGYp2vFwwf5O/mgYTvPA1uuxfWajhAPv/T5mENfCkYLW2pVPR29l22Q fhfw==
- In-reply-to: <firstname.lastname@example.org>
- List-help: <mailto:email@example.com>
- List-id: Zsh Workers List <zsh-workers.zsh.org>
- List-post: <mailto:firstname.lastname@example.org>
- Mailing-list: contact zsh-workers-help@xxxxxxx; run by ezmlm
- References: <20161209122958.GD19559@256bit.org> <email@example.com> <584AC8AC.firstname.lastname@example.org> <email@example.com> <584AEDBF.firstname.lastname@example.org> <161209165454.ZM9226@torch.brasslantern.com> <email@example.com> <161209191323.ZM9548@torch.brasslantern.com> <firstname.lastname@example.org>
On Dec 14, 1:40pm, Oliver Kiddle wrote:
} It's certainly an option to take an existing plugin manager and without
} having looked into any of them, I would tend to assume that Sebastian's
} is the best. It is also clearly very feature rich.
He does appear to have taken the practices of a number of other more
rudimentary plugin managers into account as well as going to a lot of
effort to shield plugins from each other.
} I used the wording "rudimentary plugin manager" because what I had
} in mind foremost is standardising the conventions. A basic reference
} implementation helps with documenting that and determining what issues
} there might be. But perhaps that's already known.
If there's anything Sebastian hasn't thought of yet, I haven't thought
of it either :-) but then again I missed "printf -" for a year.
} For example, I seem
} to remember something about the various frameworks causing compinit to
} be run multiple times. A pure plugin manager has no business running
} compinit even once
The plugins themselves were running "compinit" to force their supplied
completion files to be found after updating fpath. The manager resolves
this by adding a dummy compinit that queues up all the other attempted
runs until the user is ready to ask for them.
} > Although the idea with this particular file was simply to fold it in to
} > compinit.
} default_zstyle() doesn't prevent it altering an existing user's setup so
} unconditional inclusion might be a problem.
That's true, though it avoids altering any directly conflicting setup.
We'd want a way to ask that the defaults not be included, just like we
have a way to skip "compaudit".
Messages sorted by: