From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 27353 invoked by alias); 10 Feb 2016 09:23:29 -0000 Mailing-List: contact zsh-users-help@zsh.org; run by ezmlm Precedence: bulk X-No-Archive: yes List-Id: Zsh Users List List-Post: List-Help: X-Seq: 21264 Received: (qmail 11416 invoked from network); 10 Feb 2016 09:23:27 -0000 X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on f.primenet.com.au X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 autolearn=ham autolearn_force=no version=3.4.1 Date: Wed, 10 Feb 2016 09:23:22 +0000 From: Daniel Shahaf To: Sebastian Gniazdowski Cc: Zsh Users Subject: Re: Forgetting about compinit with manual alteration of _comps Message-ID: <20160210092322.GB6339@tarsus.local2> References: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) Sebastian Gniazdowski wrote on Tue, Feb 09, 2016 at 11:28:10 +0100: > The bottom line is: a software package providing trivial completions > can do autoload/_comps alteration to make users happy. If they called > compinit before – completions will work. If they call compinit after – > completions will work also. Any nastiness in this? As far as I know, $_comps is an implementation detail, meaning it may change incompatibly without notice. Instead of assigning to $_comps, you should use 'compdef _mycmd mycmd', which is a stable API. However, I'm not sure making a plugin loadable _either before or after_ compinit is a good idea. It may be simpler for plugin authors to expect to be loaded in one circumstance (say, after compinit) and ensure they emit a clear error message in the other circumstance (say, before compinit), than to eternally support two codepaths. Cheers, Daniel