From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 1561 invoked by alias); 28 Jan 2016 07:10:23 -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: 21192 Received: (qmail 16769 invoked from network); 28 Jan 2016 07:10:21 -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-sha256; c=relaxed/relaxed; d=brasslantern-com.20150623.gappssmtp.com; s=20150623; h=from:message-id:date:in-reply-to:comments:references:in-reply-to :comments:in-reply-to:comments:to:subject:mime-version:content-type; bh=yXx8pnbZJ60B+GqRyPpFiZwN3Wb+IEPRS5h6sI5aGMY=; b=OMxXG6Ii/5RyY6zZKyw5ouHy+j+9kZrAkNrS0qf6DP8xqUEK/pW4HMgiJ/aA1Exo/t dE+Bek1vfnN7W6SsUQ/m9Gp3+opnbGpG2Pg6JMTsJWlPPUnepjOHzL5Ib1BaLuWCkENV 08rXTl30XrtM/3/9P2uWpMeVT0+cm2Ta2CnrAUW/M9nrpJS1DvquJ8dMWQFSoF3e9hjd 9mIuvkaWDdehNPQx6n5t4F2fJCULr8/Fi+d7Xa+uFyhj87s8dak+OZbgK1uSPeEm/YRz bzYKpiZX5S4rF5grOU7AvEV7oGFzWurI9y8Iz1mZIH8xyWsmof3aP3O0RhlZu025NTb3 itMw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:message-id:date:in-reply-to:comments :references:in-reply-to:comments:in-reply-to:comments:to:subject :mime-version:content-type; bh=yXx8pnbZJ60B+GqRyPpFiZwN3Wb+IEPRS5h6sI5aGMY=; b=jZ0iWNeEszYI+whgXbbZt4yCAozAFqEuJk1IOmGsqHLHLvHr5bNbxeWXDK1Iz32ZcA 7KXp0X4XiZQpw1t+3nzXf90OaObCwMWuDx+bB3Ms4R2eewlIuLMPtVm56dwTaqcJ7s+y nuTrOMYIsFELHn/A8N1pRxQ+vOXW5pPxj18DEeJOnpC3MZhdmtvm0B3lYvgd/vKz6nRS GdXqVKfC2kF8o2Hp7ZH4GrXYKxCLWvsXoMpP4zymnWHbDAD8DWddhJbEGyYc8pNBCVhC g37YEHMlqEfBGtSxXxnQ4WNfLpexF9VwhrgaBDP8znw5/g/VmB7U3+tgTQxgQBBwfQFw A4Kg== X-Gm-Message-State: AG10YORiEbmQiu97vAtRHU8pZ9TFGyGvyjD0DvIlvVLQyqFubGzipKmMnENyZlM+tbsAzg== X-Received: by 10.98.42.135 with SMTP id q129mr2283951pfq.13.1453965019430; Wed, 27 Jan 2016 23:10:19 -0800 (PST) From: Bart Schaefer Message-Id: <160127231104.ZM17647@torch.brasslantern.com> Date: Wed, 27 Jan 2016 23:11:04 -0800 In-Reply-To: Comments: In reply to Sebastian Gniazdowski "How completions work, do they require fpath?" (Jan 26, 6:18pm) References: <160126232017.ZM3789@torch.brasslantern.com> In-Reply-To: Comments: In reply to Sebastian Gniazdowski "Re: How completions work, do they require fpath?" (Jan 26, 8:51pm) In-Reply-To: Comments: In reply to Sebastian Gniazdowski "Re: How completions work, do they require fpath?" (Jan 27, 8:59am) X-Mailer: OpenZMail Classic (0.9.2 24April2005) To: Zsh Users Subject: Re: How completions work, do they require fpath? MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii On Jan 26, 6:18pm, Sebastian Gniazdowski wrote: } } my current understanding of the completions is that if a file-function } with name starting with "_", and having "#compdef ..." in first line } of content, is found in $fpath, then, if compinit is run, the function } will be autoloaded and used by _main_complete. Am I missing something } here? No. } Does this mean that compinit should be best run once after all needed } fpath updates? Ideally yes, but really #compdef is just a way to have the compdef function invoked automatically for some files. If the plugin is already calling autoload + compdef directly, compinit isn't needed. Note that nothing checks for conflicting #compdef, so if two files both specify the same key bindings the one found later in fpath will create the binding, but the one found earlier in fpath will be autoloaded if the two have the same basename. (So far it has never come up for two files with the same name, though I believe there are some conflicting key bindings.) } A trick to avoid fpath for regular autoload functions has emerged on } this list. Is similar trick possible for a completion? How to load one } without running compinit and most of all, without updating fpath? There's a chunk of code near the end of compinit that handles the parsing of the #compdef lines. That would need to be extracted into its own function so it could be run repeatedly for new files. Other than that, the shadow-autoload trick already used in zplugin should work for completion autoloads, although they would not get recorded in ~/.zcompdump (and you wouldn't want them to be, in that circumstance). On Jan 27, 8:59am, Sebastian Gniazdowski wrote: } Subject: Re: How completions work, do they require fpath? } } On 27 January 2016 at 08:20, Bart Schaefer wrote: } > No, it doesn't contradict the manual. The check for a directory named } > "Base" is to distinguish "configure --enable-function-subdirs" Actually I'm only partly right about that. The real purpose of those checks in compaudit are so that for example you can start in the zsh source tree and run: Src/zsh -f fpath+=($PWD/Completion) autoload -Uz compinit _compdir=$PWD/Completion compinit -D and have everything set up to do compsys testing, without having to first "make install" etc. } So using _compdir would be a hack, and also, someone can utilize } _compdir for what's it's intended, and overwriting _compdir would } broke their setup. Correct. } So it seems that fpath is needed. Perhaps, but see other responses from Peter and above about compdef. } I wanted to have fpath "clean", and I guess I can still have it I've been a little puzzled all along about why you object to having entries in fpath. } like this: create ~/.zplugin/completions, add it to fpath, simlink } any plugin's "_*" files there. There's another possibility: use zcompile. Gather up the names of all the autoloadable files defined by the plugins, and then run for example zcompile ZPLUGINS $all_the_paths_of_autoloadable_files This will create a (large) file ZPLUGINS.zwc containing all potential autoloads. Then just add that file name (not a directory name in this special case) to fpath: fpath+=($PWD/ZPLUGINS.zwc) and you're done. Some checks that you don't clobber the file when a new shell starts up are advised, because zsh typically mmap's it and shares it.