From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 29705 invoked by alias); 1 Jun 2018 07:18:55 -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: List-Unsubscribe: X-Seq: 42911 Received: (qmail 1089 invoked by uid 1010); 1 Jun 2018 07:18:55 -0000 X-Qmail-Scanner-Diagnostics: from mail-wr0-f171.google.com by f.primenet.com.au (envelope-from , uid 7791) with qmail-scanner-2.11 (clamdscan: 0.99.2/21882. spamassassin: 3.4.1. Clear:RC:0(209.85.128.171):SA:0(-3.6/5.0):. Processed in 1.361659 secs); 01 Jun 2018 07:18:55 -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=-3.6 required=5.0 tests=BAYES_00,FREEMAIL_FROM, RCVD_IN_DNSWL_NONE,RCVD_IN_MSPIKE_H2,SPF_PASS,T_DKIM_INVALID autolearn=ham autolearn_force=no version=3.4.1 X-Envelope-From: doron.behar@gmail.com X-Qmail-Scanner-Mime-Attachments: | X-Qmail-Scanner-Zip-Files: | DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=date:from:to:subject:message-id:mail-followup-to:references :mime-version:content-disposition:in-reply-to:user-agent; bh=6DwrljUR47JhxPVV48Z4eyyFQSRBWCAems3N7f4PyKA=; b=Ngz9/qczewsnZHpAypIjox0AKWPoHVycMhA7ApSxp1bEO78rXGuxG0xpZumqDz4ezh A7KB0ZA/67E3CK6f6EZM3KMw9Z63jOe72Hbisc1AuVcElTWGxmmhFV/LZS1Hw1kLCUBg ZmY/rYEKvdYzP4YQV01ekAJtKO13lnkMNH1m8aC/M7GQieldF5lx8RNFBd27f3Ntb6BD ZH1Rrhn395ijKHEF23DtfcoHqVvrFnlv6TJ4djUY6PcyJwrv3hQo1Nf8AEarY0Vvdjj4 tKWgsbRYsIQdcvosB6TzHELmQDDVQlHNVnfRQvgIvec06tdh73GuYHAdyM+yXHwse2Kh 8flg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:subject:message-id:mail-followup-to :references:mime-version:content-disposition:in-reply-to:user-agent; bh=6DwrljUR47JhxPVV48Z4eyyFQSRBWCAems3N7f4PyKA=; b=IRLx3QNCjq7E5aP8ZXk2LYldvmoY1kyv+peEvI9kNdrbXCoLMV58t/Z2yEl8jnvHlS VcnqG8+AftbIlx4gzkc7eofvpKLfMZyFuqf4oNfRt2BtwYf2g+uvwtBEmZUWO6hI5lCL 55G+dNyP0BRyAUJKq8JQmueeno4SbfoK1VJ7AQpOIp5MAesQWQmOuIjjAsxUkU6Rni6B fjIy9GzOTVgMTaTs5MkmfgVCLUia+qUOpJYNLJUklRZjqHIja59g6UZ5SmteMOwxtNM1 7Ek1ASnPkgI9hvwVXTqfvn9W7sW2DOCJqJEN4HYKcp4rDAD5J+2HtURz+pj/SYDQ48Fc USVQ== X-Gm-Message-State: ALKqPwe6dhLmLqKcghKZsgOSN0+t+6YvHGMIlAZIjoiHEcSmSVOHV4MY I+hsJickonGm0zUjxrUuMjbL9wUm X-Google-Smtp-Source: ADUXVKJcL6pBKylIsFWSFdHJZBQoinQwetf5ShFrknRLwFRtSmRhibmQq8G7qfTFFfUdqcp/eGgmHw== X-Received: by 2002:adf:9025:: with SMTP id h34-v6mr8248693wrh.123.1527837529987; Fri, 01 Jun 2018 00:18:49 -0700 (PDT) Date: Fri, 1 Jun 2018 10:18:54 +0300 From: Doron Behar To: zsh-workers@zsh.org Subject: Re: [PATCH 1/1] Squashed commit of the following: Message-ID: <20180601071850.4z3h6cvkuvva3nby@NUC.doronbehar.com> Mail-Followup-To: zsh-workers@zsh.org References: <20180526161403.4860-1-doron.behar@gmail.com> <20180526161403.4860-2-doron.behar@gmail.com> <5942.1527504539@thecus> <20180529153821.nmwa5yojlusioxti@NUC.doronbehar.com> <13666.1527631249@thecus> <20180530124707.xp6loetwnplkypk2@NUC.doronbehar.com> <16604.1527694987@thecus> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <16604.1527694987@thecus> User-Agent: NeoMutt/20180512 Thanks again for you reply Oliver, I'll get to the issue of `ret` later since I might need your advice on the matter of installed rocks' cache policy function: You asked me in one of the previous mails whether it is possible or not to query luarocks instead of hard-coding the paths of the manifest files. To your reminder, I compared their last modified date (Thanks to you with `-nt` rather then `date -r`) with that of the cache files, here is the original version after changing to `-nt`: (( $+functions[___luarocks_installed_rocks_cache_policy] )) || ___luarocks_installed_rocks_cache_policy(){ local cache_file="$1" # TODO: use luarocks config to get these paths according to luarocks local user_manifest_file="${HOME}/.luarocks/lib/luarocks/rocks-5.3/manifest" local system_manifest_file="/usr/lib/luarocks/rocks-5.3/manifest" if [[ -f ${user_manifest_file} ]] || [[ -f ${system_manifest_file} ]]; then if [[ -f ${cache_file} ]]; then # if either one of the manifest files is newer then the cache: if [ ${user_manifest_file} -nt ${cache_file} ] || [ ${system_manifest_file} -nt ${cache_file} ]; then (( 1 )) else (( 0 )) fi else (( 1 )) fi else (( 1 )) fi } The good news as for the TODO comment I wrote there is that it is possible to do so: Using `luarocks config --lua-ver` for the version (now hard-coded to 5.3) and `luarocks config --rock-trees`. However, the bad news is that I'm afraid that calling `luarocks config` twice like that whenever I query the cache validity, is a huge performance hit. The solution which will most likely best solve this issue is to use a similar cache mechanism for these values as well. This *inner* cache's validity should be checked against the cache files' and the luarocks configuration files (system and user) modification date. What makes this even more complicated is the fact that the locations of the user and system configuration file can be queried for that as well. And yet again, even running `luarocks` twice for getting these values will bring a performance hit as well. Anyway, I've come to the conclusion that I'll need to write inside this cache policy function what's written in the cache related functions (mostly `_store_cache` and `_retrieve_cache`) and customise it for my parameters, it'll take some time so I'll send it here when it is ready. I think it's better to take care of `ret` afterwards. On Wed, May 30, 2018 at 05:43:07PM +0200, Oliver Kiddle wrote: > Doron Behar wrote: > > O.K, I used `ret` instead yet currently I don't see any use in this > > variable since I didn't structured the completion file with `return ret` > > at the end of any of the functions as I've seen in other completion > > functions I read. > > You need something like it in the final function. You're calling > _arguments and ignoring the return status from it. This can break things > - approximate completion mostly. > > It's only really that function where you need it. > > > Jesus, using `zstyle` is complicated, I hope I'll master this skill one > > day.. Where can I find in the documentation more explanations about the > > relation between zstyle and completion functions? > > It looks worse than it is. You can see the styles and contexts for a > particular completion by pressing Ctrl-X h instead of Tab. With a > numeric argument (Escape 1 for emacs mode) it provides more detail. > > Oliver